Industrial process control systems as data centers for industrial process plants

Abstract

To provide an industrial decentralized process control system (DCS) capable of providing a new data center for a plant.SOLUTION: An industrial decentralized process control system (DCS) includes a data center that stores physical components of a plant and a plant information model including a description of a control framework and a control network. An API provides, to a DCS application, access to the model, and also provides access to the data center storing a basic structure and functions, and the DCS can automatically generate another structure and functions from the basic structure and functions to previously set a model, and automatically generate a variety of applications and routines to be used during runtime operation of the DCS and plant.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] FIELD OF THE INVENTION This application relates generally to industrial process control systems for industrial process plants, and more particularly to industrial process control systems that are data centers for industrial process plants. [Background technology]

[0002] A distributed industrial process control system, such as those used to manufacture, refine, convert, generate, or produce physical materials or products in chemical, petroleum, industrial, or other process plants, typically includes one or more process controllers communicatively coupled to one or more field devices via a physical layer that may be an analog bus, a digital bus, or a combined analog / digital bus, or may include one or more wireless communication links or networks. The field devices may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, water level, and flow sensors) located within the process environment of the industrial process plant (interchangeably referred to herein as the “field environment” or “plant environment” of the industrial process plant) and generally perform physical process control functions, such as opening and closing valves, measuring process and / or environmental parameters such as flow rate, temperature, or pressure, and controlling one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to the well-known FOUNDATION® Fieldbus protocol, may also perform control calculations, alarm functions, and other control functions typically implemented within a controller. A process controller is also typically located within a plant environment and receives signals indicative of process measurements made by field devices and / or other information related to the field devices, and executes control routines or applications that operate, for example, various control modules, which utilize various control algorithms to make process control decisions, generate process control signals based on the received information, and coordinate with control modules or control blocks implemented within field devices, such as HART® field devices, WirelessHART® field devices, and FOUNDATION® Fieldbus field devices.To accomplish this communication, control modules within the process controller send control signals to a variety of different input / output (I / O) devices, which then transmit these control signals over dedicated communication lines or links (communication physical layers) to the actual field devices, 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 operating or executing within the plant or system. Additionally, I / O devices, typically located within a plant environment, are generally positioned between the process controller and one or more field devices and enable communication therebetween, e.g., by converting electrical signals to digital values ​​and vice versa. Different I / O devices are provided to support field devices that use different proprietary communication protocols. More specifically, different I / O devices are provided between the process controller and each of the field devices that use a particular communication protocol, such that a first I / O device is used to support HART field devices, a second I / O device is used to support Fieldbus field devices, a third I / O device is used to support Profibus field devices, and so on. Herein, field devices, controllers, and I / O devices are generally referred to as "process control devices" and are generally located, disposed, or installed in the field environment of a process control system or plant.

[0003] Additionally, information from the field devices and process controllers is typically made available via a data highway or communication network through the process controller to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized computing devices typically located in a control room or other location away from the plant's harsher field environment, e.g., the back-end environment of a process plant. Each of these hardware devices is typically centralized throughout the process plant or throughout portions of the process plant. These hardware devices run applications that may enable operators to perform functions related to controlling the process and / or operating the process plant, such as, for example, changing settings in process control routines, modifying the operation of control modules in controllers or field devices, displaying the current state of the process, displaying alarms generated by field devices and controllers, simulating the operation of the process for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. The data highways utilized by the hardware devices and process controllers may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths, and typically use packet-based communication protocols and non-time-sensitive communication protocols such as Ethernet or IP protocols.

[0004] As an example, the DeltaV™ control system sold by Emerson Process Management includes multiple applications stored in and executed by different devices located at various locations within a process plant. Configuration applications resident in one or more workstations or computing devices allow users to create or modify process control modules and download them to dedicated distributed controllers via a data highway. Typically, these control modules are composed of communicatively interconnected function blocks, which may be objects in an object-oriented programming protocol that perform functions within the control scheme based on inputs to the control scheme and provide outputs to other function blocks within the control scheme. The configuration application may also allow configuration engineers to create or modify operator interfaces that are used by viewing applications to display data to an operator and allow the operator to change settings, such as setpoints, within process control routines. Each dedicated controller, and possibly one or more field devices, stores and executes its own controller application, which executes its assigned and downloaded control modules to implement the actual process control functions. The viewing application may run on one or more operator workstations (or one or more remote computing devices in communicative connection with the operator workstations and the data highway) and may receive data from the controller application via the data highway and display this data to a process control system designer, operator, or user using a user interface to provide any of several different views, such as an operator's view, an engineer's view, a technician's view, etc.While the data historian application is typically stored on and executed by a data historian device that collects and stores some or all of the data provided over the data highway, a configuration database application may be run on an even further remote computer attached to the data highway to store the current process control routine configuration and its associated data. Alternatively, the configuration database may be located on the same workstation as the configuration application.

[0005] As distributed industrial process control systems have evolved over time, various hardware, communication, and networking technologies have been developed and added. Thus, each new generation or iteration of hardware, communication, and / or networking technology has typically had to integrate and operate seamlessly with the significantly larger embedded base of process control devices, communication, and networking technologies of the previous generation of industrial process control systems. As a result, today's distributed industrial process control systems may typically support numerous types of analog and / or digital-specific process control communication protocols utilized by different types and / or generations of field devices (e.g., 4-20mA, OPC Unified Architecture (OPC UA) Highway Addressable Remote Transducer (HART®), CAN, FOUNDATION® Fieldbus, PROFIBUS, WirelessHART®, HART-IP, etc.), as well as numerous types of general communication and / or data protocols, such as Wi-Fi, Bluetooth, Ethernet, MQTT, AMQP, and / or other types of packet protocols, at least some of which may conform to one or more IEEE (Institute of Electrical and Electronic Engineers) standards or data networking standards, each of which may be used to communicate and store various types of data related to the operation of the industrial process plant. Additionally, while an industrial process plant is supported by a distributed industrial process control system for controlling runtime operations, the industrial process plant is also supported by other systems for managing the plant, its equipment, and its processes (e.g., plant asset management (PAM) systems, maintenance systems, diagnostic systems, simulation systems, remote monitoring and / or analysis systems, enterprise business systems, etc.), each of which may utilize its own set of communication and / or data protocols to communicate and store data related to the industrial process plant.

[0006] Thus, the different fixed networking technologies utilized in distributed industrial process control systems and other systems supporting industrial plants make it difficult, cumbersome, and costly to scale up or down the size of the plant, and for industrial process control systems to integrate with other systems in a peer-wise (e.g., horizontal) and / or hierarchical (e.g., vertical) manner (e.g., systems residing in different tiers or security levels with respect to the Purdue Model for Control Hierarchy standardized by the International Society of Automation (ISA), such as enterprise systems, remote systems, cloud-based systems, etc.) while maintaining strict security requirements. Furthermore, process plant-related data generated by disparate sources and communicated over disparate networks requires a significant amount of data integration, which can potentially drain processing power and network bandwidth, in order to be utilized by applications that provide actionable information to plant personnel. Summary of the Invention

[0007] The industrial distributed process control system (DCS) provides a new data center for industrial process plants. More specifically, this new process plant data center significantly decouples process plant-related data from the fixed networking technologies of current industrial process control systems and other associated horizontal and / or vertical systems (e.g., plant asset management (PAM) systems, maintenance systems, diagnostic systems, simulation systems, remote monitoring and / or analysis systems, enterprise business systems, etc.), thereby facilitating industrial process plant scalability and data integration and facilitating the availability of process plant-related data for application use in a highly secure manner.

[0008] Generally speaking, an industrial process plant data center includes a plant information model that includes a representation or description of the physical industrial process plant, a representation or description of the control strategies utilized by the industrial process plant, and a representation or description of the industrial process control system, all of which are represented and / or described within the plant information model using a modeling language commonly utilized across all descriptions. In addition, the process plant data center includes a generic framework that provides generic structures and generic functions that can be utilized automatically or manually as building blocks for other structures and functions, as well as applications utilized in the industrial distributed process control system. Furthermore, the process plant data center exposes or otherwise provides application programming interfaces (APIs) that enable applications of the DCS to securely access and / or retrieve the process plant information, generic structures, and / or generic functions for use by the applications.

[0009] In one embodiment, an industrial distributed process control system for an industrial process plant is disclosed that includes a set of pluggable, interchangeable hardware modules, each pluggable hardware module in the set including a plurality of interface ports configured to deliver one or more types of I / O data utilized in industrial process control, one or more processors, and one or more tangible, non-transitory memories.

[0010] The one or more tangible, non-transitory memories of each pluggable hardware module store a discovery engine including first computer-executable instructions that, when executed by the one or more processors, cause each pluggable hardware module, upon power-on, to automatically sense a respective I / O type of each interface port included in the plurality of interface ports of the pluggable hardware module, bind to each interface port a respective I / O data delivery mechanism corresponding to the respective I / O type to each interface port, and discover one or more physical components of an industrial process plant to which each pluggable hardware module is communicatively connected via the plurality of interface ports, the one or more physical components communicatively connected to each pluggable hardware module including respective field devices configured to perform physical functions for controlling an industrial process during runtime operation of the industrial process plant.

[0011] Additionally, the first computer-executable instructions of the discovery engine, when executed by the one or more processors, cause each pluggable hardware module to further preconfigure at least a portion of a plant information model of the DCS based on the discovery of the one or more physical components, the plant information model including a description of a control framework for the industrial process plant and a description of a control network for the industrial process plant utilized to control the industrial process during runtime operation of the industrial process plant. The control framework for the industrial process plant defines logical control identifiers for each of the control components of the DCS and hierarchical relationships between the control components, the control components including the discovered field devices. The control network includes the discovered field devices, respective interface ports through which the field devices are communicatively connected to each pluggable hardware module, and control routines provided on each pluggable hardware module.

[0012] The one or more tangible non-transitory memories of each pluggable hardware module further store an execution engine including second computer-executable instructions that, when executed by the one or more processors, cause each pluggable hardware module to execute a control routine and cause a respective I / O data delivery mechanism bound to a respective interface port to deliver data between the field device and the control routine, thereby controlling an industrial process.

[0013] In one embodiment, a method for initializing an industrial distributed process control system (DCS) for an industrial process plant is disclosed. The industrial distributed process control system includes a set of pluggable, interchangeable hardware modules, the method including, at each pluggable hardware module, sensing, upon power-on of the pluggable hardware module, a respective I / O type of each interface port included in a plurality of interface ports included in the pluggable hardware module, binding, by each pluggable hardware module, a respective I / O data delivery mechanism corresponding to the respective I / O type to each interface port, and discovering, by each pluggable hardware module, one or more physical components of the industrial process plant to which each pluggable hardware module is communicatively connected via the plurality of interface ports. The one or more physical components include field devices communicatively connected to each pluggable hardware module via the respective interface ports, the field devices configured to perform physical functions to control the industrial process during runtime operation of the industrial process plant.

[0014] The method further includes preconfiguring at least a portion of a plant information model of the DCS based on discovery of one or more physical components by each pluggable hardware module, the plant information model including a description of a control framework for the industrial process plant and a description of a control network for the industrial process plant utilized to control the industrial process during runtime operation of the industrial process plant. The control framework for the industrial process plant defines logical control identifiers for each of the control components of the DCS and hierarchical relationships between the control components, and the field devices are included in the control components. The control network includes the field devices, their respective interface ports, and control routines provided in each pluggable hardware module.

[0015] Additionally, the method includes executing, by each pluggable hardware module, a control routine and a respective I / O data delivery mechanism bound to the respective interface port to deliver data between the field device and the control routine, thereby controlling the industrial process.

[0016] In one embodiment, an industrial distributed process control system (DCS) for an industrial process plant is disclosed. The industrial distributed process control system includes a data center including a plant information model stored in one or more tangible, non-transitory memories of the DCS. The plant information model uses a modeling language to describe (i) a set of physical components of the industrial process plant, where a description of the set of physical components indicates the location of each of the set of physical components and each physical interconnection between the set of physical components, (ii) a control framework for the industrial process plant, where the control framework defines a hierarchical relationship between the set of control components of the DCS and a logical control identifier for each of the set of control components, where the control components include at least a portion of the set of physical components, and (iii) a control network for the industrial process plant utilized to control the industrial process during runtime operation of the industrial process plant, where the control network includes at least a portion of the set of control components.

[0017] The data center further includes a set of application programming interfaces (APIs) stored in one or more tangible, non-transitory memories of the DCS and exposed to at least one of the control routines or I / O data distribution mechanisms of the DCS to provide the at least one of the control routines or I / O data distribution mechanisms with access to the plant information model via a modeling language, the modeling language including abstractions of multiple data formats utilized by the DCS. At least one of the control routines or I / O data distribution mechanisms executes with corresponding physical components located within the industrial process plant by utilizing information obtained from the plant information model, thereby controlling the industrial process during real-time operation of the industrial process plant. [Brief explanation of the drawings]

[0018] [Figure 1]1 illustrates an exemplary industrial process plant data center included in an industrial distributed process control system of an industrial process plant data ecosystem for a physical industrial process plant. [Figure 2] 2 shows a block diagram of an exemplary pluggable, interchangeable hardware module that may be included in the industrial distributed process control system of FIG. 1. [Figure 3] 2 illustrates a flow diagram of an exemplary method for initializing an industrial distributed process control system of an industrial process plant, such as the industrial distributed control system illustrated in FIG. 1 . DETAILED DESCRIPTION OF THE INVENTION

[0019] 1 illustrates an exemplary industrial process plant data center 10 within an industrial process plant data ecosystem 12 for a physical industrial process plant 15. As shown in FIG. 1, the process plant data center 10 includes a plant information model 18, a set of application programming interfaces (APIs) 20, and a generic framework 22. The plant information model 18 uses a modeling language to provide a representation, description, or model of the physical industrial process plant 15, a representation, description, or model of the control framework utilized by the industrial process plant 15, and a representation, description, or model of the control network of the industrial process plant 15. Generally speaking, the plant information model 18 is the basis by which components of the plant ecosystem 12 describe, reference, and communicate physical, logical, and / or control-related information and data associated with the industrial process plant 15. Thus, the plant information model 18 uniformly describes the physical components, control framework, and control network of the industrial process plant by using a modeling language that abstracts information from multiple data sources (e.g., the physical components themselves, one or more databases associated with the industrial process plant, such as a configuration database, an asset management database, and / or other data sources) to uniformly provide the description in the plant information model 18. For example, the DCS 25 may convert or abstract data in various data formats obtained from various data sources into a common modeling language utilized by the plant information model 18 and may use the modeling language to store the information corresponding to the plant information model. At least a portion of the plant information model 18 may be automatically generated and pre-configured upon initialization of the industrial distributed control system (DCS) 25 in which the data center 10 is included and upon physical connection of the DCS 25 to the industrial process plant 15, as described in more detail elsewhere in this disclosure.

[0020] The generic framework 22 provided by the plant data center 10 includes a set of generic structures 22a and a set of generic functions 22b, which are typically stored in the memory of the data center 20 at some point prior to initialization of the data center 10. The generic structure 22a includes generic structure templates for defining and / or describing various types of physical components of the industrial process plant 15 (e.g., controllers, sensors, pumps, valves, actuators, safety devices, I / O devices, routers, access points, etc.), as well as generic structure templates for defining and / or describing various types of logical and control components of the industrial process plant 15, such as blocks, parameters, I / O cards and / or other hardware components, nodes, node subsystems, etc. The generic functions 22b include a set of basic functions utilized in control and / or I / O data distribution. For example, a set of base functions may include, for example, primary generic control functions and primary generic I / O functions (e.g., primary generic "I / O data distribution functions") that may be utilized directly in the process control routines of DCS 25 to control an industrial process. Generic functions 22b may also include secondary or support functions that do not themselves directly perform process control or I / O data distribution, but may otherwise operate on data generated from the control of the industrial process, e.g., alarms, monitoring, analysis, HMI, trending, etc. However, in some implementations, outputs from some generic support functions may affect process control behavior.

[0021] Data center 10 is included in a distributed industrial process control system (DCS) 25 of industrial process plant 15, which may include a control cluster 28 and an input / output (I / O) cluster 30 (interchangeably referred to herein as an “I / O data distribution cluster 30”). Generally speaking, control cluster 28 and I / O cluster 30 of DCS 25 include respective sets of computational modules that operate in conjunction during runtime operation of the physical industrial process plant 15 to control one or more industrial processes of industrial process plant 15 by utilizing plant information model 18 and, optionally, generic framework 22.

[0022] In an embodiment, ecosystem 12 generally further includes a set of DCS operator user interfaces 32 that enable a plant operator or user to view, monitor, adjust, and respond to runtime process operations of plant 15. DCS operator user interfaces 32 may include a set of local user interfaces 32a that execute on a computing device located in a control room or other back-end environment of physical industrial plant 15 that is typically shielded from the harsher field environment of physical industrial plant 15 where physical materials are processed. Additionally or alternatively, DCS operator user interfaces 32b may include a set of remote user interfaces 32b that execute remotely from industrial process plant 15, for example, within or associated with cloud component 50 of industrial process plant ecosystem 12. In some embodiments, ecosystem 12 also includes one or more local and / or remote assistance engines 35 that provide intelligent assistance to operator user interfaces 32a, 32b (e.g., operator assistance engines 35a, 35b) and / or DCS 25 control operations (e.g., control assistance engines 35c, 35d), as described in more detail elsewhere in this disclosure. While FIG. 1 depicts DCS operator user interface 32a and assistance engines 35a, 35d as separate from DCS 25, in some embodiments, at least a portion of DCS operator user interface 32a and / or assistance engines 35a, 35d are included in DCS 25.

[0023] The set of APIs 20 of the data center 10 is exposed or otherwise made available to a set of applications 40a that may utilize the APIs 20 to access the plant information 18 and the generic framework 22 provided by the data center 10, for example, by utilizing a common modeling language. The applications 40a may be stored, for example, in an application library 45 of the industrial process plant 15. In some embodiments, one or more third-party extensions 48 may utilize at least a portion of the set of APIs 20 to access the plant information 18 and the generic framework 22, and applications 40b that utilize the third-party extensions 48 may also be stored in the plant application library 45. Some of the applications 40a, 40b stored in the library 45 may have instances executing, for example, in the control cluster 28, the I / O cluster 30, and / or other clusters 31 (e.g., the compute cluster 26 of the DCS 25). Some of the applications 40a, 40b may, in embodiments, be DCS operator user interfaces 32 and / or one or more support engines 35. Some of the applications 40 a, 40 b may be utilized by other applications 40 a, 40 b in embodiments. Additionally or alternatively, applications executing on the DCS compute cluster 26, the DCS operator user interface 32, and / or the support engine 35 may directly access the plant information model 18 and / or the generic framework 22, for example, via a set of APIs 20.

[0024] In an embodiment, the industrial process plant ecosystem 15 includes a plant cloud computing component 50, as represented by reference 40c, that may store and / or host at least a portion of the applications of the plant application library 45. The applications 40c residing in and / or executing in the cloud may include, for example, one or more applications 40a and / or one or more applications 40b. The plant cloud component 50 may be communicatively connected to any number of user computing devices 52 via one or more networks 55. The one or more networks 55 may include any number of public and / or private communication and / or data networks, and may include any number of wired and / or wireless communication and / or data networks. Similarly, although not shown in FIG. 1 , the plant cloud component 50 may be communicatively connected to other components of the plant application library 45 and / or DCS 25 via one or more networks, such as network 55. For example, the DCS 25 may include one or more edge gateways through which the plant cloud component 50 is communicatively connected to the DCS 25 and the plant application library 45.

[0025] Accordingly, at least some of the applications 40c provided by DCS 25 to reside on the plant cloud computing component 50 may be made available to various user computing devices 52, such as handheld portable mobile devices 52a, laptops or other types of personal computers 52b, vehicle display systems 52c, etc., via one or more networks 55, so that operators and / or users can remotely monitor and perform functions related to controlling a process and / or operating the process plant 15 during runtime operation, and so that other users (such as Level 3 or higher users) can monitor and adjust respective functionality based on the runtime operation of the plant 15, e.g., supply chain management, maintenance, parts and equipment sequencing, etc. For example, some of the applications 40c may be downloaded from the plant cloud component 50 to the user computing devices 52, and / or some of the applications 40c hosted on the plant cloud component 50 may be accessed by various user computing devices 52 via client / server, web services, or other suitable access mechanisms. For example, various DCS operator interfaces 32b and operator assistance engines 35b may be implemented in a set of applications 40c in the plant cloud component 50 and made available to the user computing devices 52, so that the DCS operator interfaces 32b and operator assistance engines 35b may be conveniently and securely provided on the user computing devices 52.

[0026] In an embodiment, at least some of the applications 40c hosted within the plant cloud computing component 50 may be made available via the network 55 to one or more other systems 58 associated with the industrial process plant 15. At least some of the other systems 58 may be physically located in geographic locations physically distant from the physical location of the industrial process plant 15, and / or at least some of the other systems 58 may be physically located in proximity to or even at the physical site of the industrial process plant 15. The other systems 58 may include tiered or different level systems associated with the physical industrial process plant 15 (e.g., systems “vertically integrated” with the DCS 25), such as enterprise business systems, systems associated with other plants, third-party vendor systems, etc. The other systems 58 may include peer systems of the DCS 25 associated with the physical industrial process plant 15 (e.g., systems “horizontally integrated” with the DCS 25), such as asset management, maintenance, diagnostics, simulation, remote monitoring, analytics, and / or other systems. It should be noted that in embodiments, at least some of the functionality of the peer systems of DCS 25 may be implemented within plant ecosystem 12 via applications 40. For example, an analysis system or a simulation system may be implemented via a respective application 40. However, peer system functionality implemented within plant ecosystem 12 via applications 40 does not exclude other peer system functionality that is additionally or alternatively implemented within ecosystem 12 by other computing systems 58, such as when the other computing systems 58 include legacy or embedded peer systems. Indeed, in embodiments, at least some of the peer systems of DCS 25 may be implemented using a combination of applications 40 and other systems 58, as desired.

[0027] The following sections provide additional details of the components of the industrial process plant ecosystem 12, as well as their components, functionality, behavior, and usage.

[0028] Data Center As described above, the data center 10 for the industrial process plant 15 includes a plant information model 18, a set of APIs 20, and a generic framework 22, where the generic framework 22 includes a set of generic structures 22a and a set of generic functions 22b. Generally speaking, the platform supporting the data center 10 includes one or more processors, one or more tangible computer-readable memories, and computer-executable instructions stored in the one or more tangible computer-readable memories that, when executed by the one or more processors, cause the data center 10 to generate, maintain, and update the plant information model 18, provide, and optionally modify the generic framework 22, and publish, provide, and optionally modify the set of APIs 20. In an embodiment, the data center 10 may be pre-configured (e.g., immediately available) with a pre-selected set of generic structures 22a and generic functions 22b, and / or a pre-selected set of APIs 22, which may be utilized to create other functions and applications of the DCS 25, for example, automatically by the DCS 25 and / or manually with operator or engineer intervention.

[0029] The plant information model 18 of the data center 10 is the basis by which components of the plant ecosystem 12 describe, reference, and communicate information and data related to the industrial process plant 15. The plant information model 18 utilizes a common modeling language to represent or describe the industrial process plant and portions thereof from various physical and / or logical views or frames of reference, such as a physical plant description, a control strategy or control framework description, and a control network description of the industrial process plant 15.

[0030] Specifically, within plant information model 18, the physical plant description of physical industrial process plant 15 includes a description, representation, or model of the physical components of plant 15 (such as instruments, devices, and other physical equipment of plant 15), their physical locations within plant 15, and their physical interconnections. For example, the physical plant description of plant 15 includes a description of the field devices installed within plant 15 and their respective connections to networks, power sources, each other, etc. This view of plant 15 within plant information model 18 may be utilized, for example, to obtain maintenance information, perform cause-and-effect analysis based on the physical interconnections, etc.

[0031] The control strategy or control framework description of the plant 15 in the plant information model 18 includes a description, representation, or model of the control components of the industrial process plant 15 from a logical view, such as fields, areas, units, equipment modules, control modules, control elements, etc., and their hierarchical relationships. The control components are defined within the control strategy or framework by their unique logical control identifiers (e.g., device tags, data tags, and / or other types of logical control identifiers). This view of the plant 15 can be utilized to provide the control framework, for example, by organizing the control and scoping names of the various control components to better understand their roles and relationships with respect to process control.

[0032] The control network description of the industrial process plant 15 in the plant information model 18 extends the control components of the control strategy to add descriptions of the interconnections and associations of the control components with other control-related components and devices of the plant 15, thereby describing, representing, or modeling the process control and safety network of the plant 15 and the other components and devices contained therein. For example, the control network description may provide descriptions of the configuration stations and / or user interfaces, operator stations and / or user interfaces, host computers, controllers (control and / or safety), I / O devices and / or other distribution mechanisms, smart devices, gateways, routers, etc., their respective logical control identifiers (if any), and the interconnections and associations of the various control components to form the control and safety network of the industrial process plant 15.

[0033] In an embodiment, plant information model 18 also maintains and updates the state of each of the physical industrial process plant 15 and its physical components, and maintains / updates the state (e.g., operational state) of each of at least a portion of the logical control components and / or control processes of plant 15. For example, a common modeling language may be utilized to maintain and update the physical and / or logical states of various physical and / or logical components and elements defined within plant information model 18. Of course, other information describing and / or relating to the physical and / or logical components of physical process plant 15 may be stored and maintained within plant information model 18.

[0034] The generic framework 22 of the data center 10 provides a set of generic structures 22a and a set of generic functions 22b. Typically, the generic structures 22a may provide templates for definitions or descriptions of different types of physical and logical components of the industrial process plant 15 and the DCS 25, such as instruments, devices, networking and other types of equipment, blocks, parameters, I / O cards and / or distribution mechanisms, subsystems, etc. Similarly, the generic functions 22b may provide templates for basic or commonly utilized functions within the industrial process plant 15, such as I / O data distribution and control functions. For example, the generic functions 22b may include a set of basic control functions corresponding to advanced control, regulatory control, batch control, simple sequencing, interlocks, safety shutdown, adaptive control, event-based control, reinforcement learning, and / or other control functions. Additionally or alternatively, generic functions 22b may include a set of basic I / O data distribution functions, such as analog I / O functions, discrete I / O functions, motion I / O functions, near-infrared (NIR) I / O functions, other types of I / O transport functions, sampling functions, signal conditioning functions, and / or other I / O data distribution functions. Still additionally or alternatively, generic functions 22b may include a set of basic support functions, such as functions for alarms, history, trending, diagnostics, condition monitoring, descriptive analytics, predictive analytics, reinforcement learning, buses / other communication paths, I / O data transfer, user interfaces, etc. Generally speaking, generic functions 22b may be used immediately to perform control functions, I / O data distribution functions, and / or support functions, and / or generic functions 22b may be used as building blocks and combined in various ways to create more complex control functions, I / O data distribution functions, and / or support functions.Thus, during configuration of any of the components of the industrial process plant ecosystem 12 (e.g., the control cluster 28, the I / O cluster 30, other parts of the DCS 25, the operator interface 32, the support engine 35, the applications 40, etc.), various generic structures 22a and / or generic functions 22b may be combined, scripted, and / or otherwise customized or configured to form various applications 40 and / or functions that will execute on the respective industrial process plant ecosystem components. The creation and configuration of functions and / or applications 40 to execute within the plant ecosystem 12 is described in more detail elsewhere herein.

[0035] The data center 10 provides access to the plant information model 18 and generic framework 22 via a set of application programming interfaces (APIs) 20 or other suitable access mechanisms, which may be exposed or otherwise provided to applications and processes external to the data center 10, utilizing the common modeling language of the plant information model 18. In this manner, the data center 10 protects its content from damage or attack and more easily maintains the fidelity of its content. Various applications 40 that execute throughout the industrial process plant ecosystem 12 may be created by obtaining selected generic structures 22 a and / or generic functions 22 b configured based on information stored in the plant information model 18 via the set of APIs 20. Advantageously, the set of APIs 20 supports third-party extensions 48, whereby third-party applications 40 b may be created based on selected information stored in the plant information model 18 and / or based on the generic framework 22 provided by the data center 10.

[0036] Distributed Industrial Process Control Systems (DCS) The DCS 25 of the industrial process plant 15 includes a data center 10 and a set of physical computing modules 26, each including a respective processor, memory, and interface / networking mechanism. As shown in FIG. 1 , the computing modules of the DCS 25 include a cluster of control computing modules 28 (e.g., a “control cluster” 28), a cluster of I / O computing modules (e.g., an “I / O cluster” 30), and a set of other computing modules 31.

[0037] The control cluster 28 includes a subset of the computational modules 26 of the DCS 25, which subset is specifically configured with and / or configured to execute or operate the control routines. The control routines may include one or more functions or applications that are stored in one or more memories of the control cluster 28 and executed by one or more processors of the control cluster 28 to perform industrial process control functionality. For example, one or more applications 40 executable to perform process control functionality may be downloaded from a plant application library 45 and reside on and execute on the control cluster 28. The control routines may provide various types of industrial process control functionality, such as advanced control, regulatory control, batch control, simple sequencing, interlocks, safety shutdown, adaptive control, event-based control, reinforcement learning, etc. As described above, to generate the control routine functions and applications 40, the selected generic structures 22 a and generic functions 22 b may be configured and / or combined with respect to the control strategies and control networks defined by the plant information model 18 to generate functions and applications that provide primary control functionality, e.g., control functionality that operates directly on data generated by field devices and other control components to generate control signals that control the behavior of other control components. In addition, some of the functions and applications 40 executed by the control clusters 28 may be configured, based on the generic structures 22 a and functions 22 b, to perform secondary control functionality that may affect the behavior of the primary control functionality, e.g., monitoring functions, analysis functions, etc., and / or otherwise relate to primary process control, e.g., alarm functions, trend functions, etc. For example, in the control clusters 28, secondary predictive analysis functions may operate in real time on information generated by various devices and / or primary control functionality during runtime operation of the plant 15 to monitor whether a process is predicted to be out of tolerance.If the secondary predictive analytics function predicts that the process is out of tolerance, it may generate and send appropriate control signals to various other control routines executing in cluster 28, thereby automatically maintaining the process within tolerance. In another embodiment, in control cluster 28, the secondary condition monitoring function may detect that the process has transitioned to a different state, and upon detection, the secondary condition monitoring function may automatically generate appropriate control signals to various other control routines executing in cluster 28 to return the process to its previous state.

[0038] Similarly, I / O cluster 30 may include a subset of computing modules 26 specially configured with an I / O data delivery mechanism, which may include one or more applications, modules, algorithms, and / or functions stored in one or more memories of I / O cluster 30 and executed by one or more processors of I / O cluster 30 to accomplish the I / O data delivery mechanism. For example, one or more applications 40 executable to implement the I / O data distribution mechanism may be downloaded from the plant application library 45 and reside on and execute on the I / O clusters 30. However, unlike the control clusters 28, the I / O clusters 30 or the applications executing thereon are bound to various types of physical I / O and sampling ports or interfaces of the DCS 25 (e.g., one or more physical ports and / or physical interfaces, each not separately shown in FIG. 1 but configured to support one or more types of I / O such as analog, discrete, motion, near-infrared (NIR), APL Ethernet, non-APL Ethernet, serial, motion, Railbus, HART, WirelessHART, Fieldbus, Profibus, etc.), through which various networks and physical devices of the physical process plant 15 may be communicatively coupled to the DCS 25. For ease of reading herein, and not by way of limitation, such I / O and sampling ports and / or interfaces are collectively and interchangeably referred to herein as “I / O ports,” “I / O interface ports,” “interface ports,” or “I / O physical interfaces.” In any event, selected generic structures 22 a and generic functions 22 b related to I / O distribution may be configured and / or combined with respect to descriptions of the plant 15, e.g., physical description, control strategy description, and control network description, provided by the plant information model 18, to generate I / O data distribution mechanisms and applications 40 that may execute in the I / O cluster 30.Similarly, at least some of the bindings between I / O data delivery mechanisms and physical I / O ports may be automatically determined by DCS 25 based on information stored in plant information model 18.

[0039] Generally speaking, selected generic structures 22a and generic functions 22b of framework 22 may be configured, combined in a desired manner, and pre-configured or scripted with specific component and / or element names, parameter values, etc., based on information provided by plant information model 18, to generate control routines and / or I / O data distribution mechanisms executed by control cluster 28 and I / O cluster 30. At least some of applications 40 may be automatically configured, generated, and / or created by DCS 25 and assigned to respective compute modules 26, as described in more detail elsewhere in this disclosure. Thus, during runtime operation of industrial process plant 15, control cluster 28 and I / O cluster 30 execute their respective modules, routines, mechanisms, and / or functionality, and I / O may be streamed between control cluster 28 and I / O cluster 30 modules, thereby controlling processes within industrial plant 15.

[0040] In view of the above, scaling of control cluster 28 and scaling of the logical functionality of I / O cluster 30 (e.g., expanding and / or contracting the logical functionality provided by control cluster 28 and / or I / O cluster 30) may be readily accomplished by simply adding or removing compute modules to meet the computing, functionality, bandwidth, response time, and / or other performance requirements of control cluster 28, I / O cluster 30, and / or DCS 25. For example, upon startup of DCS 25, at least a majority of the compute modules of DCS 25 may be included in a pool of generic compute modules 31, and various compute modules 31 of the pool may be assigned to operate as part of control cluster 28 and / or I / O cluster 30 as compute modules are needed to execute various control routines and / or I / O data delivery mechanisms. Additional generic computing modules 31 may be added to the control cluster 28 and / or the I / O cluster 30 to support scaling up of the DCS 25, and various computing modules included in the control cluster 28 and / or the I / O cluster 30 may be deactivated and returned to the pool 31 to support scaling down of the DCS 25, for example.

[0041] Moreover, during runtime operation, DCS 25 may advantageously dynamically balance the load of the compute modules of each cluster 28, 30 (and, in some implementations, collectively between or across both compute modules of clusters 28, 30) through (re)distribution of functionality, modules, and / or other control and / or I / O logic operations, so that the workload is more evenly distributed among the physical compute modules. For example, DCS 25 may automatically allocate various control routines to run on the physical compute module that has more availability, e.g., when an additional compute module is added, when an existing compute module is removed, or at any time during runtime operation of DCS 25. Thus, in some circumstances, a single compute module may simultaneously operate as both part of control cluster 28 and part of I / O cluster 30.

[0042] The logical control functionality provided by control clusters 28 of DCS 25 may include primary control functionality such as, for example, advanced control, regulatory control, batch control, simple sequencing, interlocks, safety shutdown, adaptive control, event-based control, reinforcement learning, etc. As described above, such control functionality may be implemented in control clusters 28 by configuring and combining selected generic structures 22 a and generic functions 22 b with respect to control strategies and control systems defined by information provided by plant information model 18. In addition, some control routines executed by control clusters 28 may be configured to also include one or more other types of secondary control functionality (e.g., monitoring functions, analytical functions, etc.) that may affect the control performed by the control routine.

[0043] The logical I / O functionality provided by I / O clusters 30 of DCS 25 may include I / O distribution to and from various types of physical I / O ports and sampling ports, e.g., analog, discrete, motion, near-infrared (NIR), etc. In some embodiments, I / O clusters 30 also provide signal conditioning. Similar to logical control functionality, logical I / O functionality may be implemented in I / O clusters 30 by configuring selected generic structures 22 a and generic functions 22 b with respect to I / O or data distribution requirements based on information provided by plant information model 18 to generate I / O data distribution mechanisms executed by I / O clusters 28. At least some of the I / O data distribution mechanisms may be bound (e.g., assigned or associated) to particular types of physical I / O ports of DCS 25, for example.

[0044] Compute modules 31 of DCS 25 that are not assigned to run as part of control cluster 28 or as part of I / O cluster 30 may be idle, designated and configured as hot spares for other compute modules, or assigned to run during runtime operation of industrial process plant 15 to perform other functionality to support DCS 25. For example, various physical compute modules 26 may be configured to manage, provide, and / or host plant application library 40, to provide or host operator user interface 32, to provide or host assistance engine 35, and / or to provide or host other functionality. At least some of the compute modules 26 of DCS 25 may be pre-configured (e.g., immediately available) to provide automatic discovery of I / O ports and devices communicatively connected to DCS 25, and automatic generation of plant information model 18 and, optionally, any additional functionality and applications corresponding to plant information model 18, as described elsewhere in this disclosure. At least some of the computing modules 26 may be pre-configured (e.g., immediately available) to be administrators or managers of the computing modules 26, and may therefore be configured to perform functionality such as monitoring the available resources and status of the computing modules 26, (re)allocating various functionalities to various computing modules, etc.

[0045] Operator Interface As mentioned above, the DCS operator user interface 32 (interchangeably referred to herein as a human-machine interface 32 or HMI 32) allows an operator or user to view and perform functions related to controlling a process and / or operating the process plant 15 during runtime operation, such as changing settings, modifying the operation of control modules in controllers and / or field devices, viewing the state and / or status of the process and its components, viewing alarms, responding to various runtime events, etc. The operator user interface 32 may also include an intelligent interface that allows the operator to search or query the DCS 25 for desired information, as well as to filter, group, sort, and / or rearrange the way information is visually and / or audibly presented by the operator user interface 32. In an embodiment, the operator user interface 32 may provide the operator the ability to verbally query, instruct, and / or intelligently interact with the DCS 25 via the operator interface 32, e.g., in a hands-free manner, to perform desired functions related to controlling a process and / or operating the process plant 15. In an embodiment, some investigative functions, such as diagnostics and / or analysis, may be initiated and monitored via the operator user interface 32 .

[0046] 1 , one or more operator user interfaces 32 a may execute on a local computing device (e.g., an operator station) located on-site at or near the industrial process plant 15, for example, in the back-end environment of the plant 15, or otherwise at the same security level as the DCS 25, e.g., Level 2 or 3 of the Purdue Model. For example, some local operator user interfaces 32 a may be downloaded from the library 45 and executed on the local computing device or operator station. Additionally or alternatively, some local operator user interfaces 32 a may be hosted on-site by one or more designated computing modules 26, and the local computing device may access the hosted user interfaces 32 a, for example, as a website, a service, etc.

[0047] Additionally or alternatively, one or more operator user interfaces 32b may be provided remotely via the plant cloud computing component 50 and one or more personal computing devices, such as a mobile device 52a, a laptop or tablet 52b, a vehicle display 52c, etc. For example, some remote operator user interfaces 32b may be downloaded from the plant cloud component 50 and executed on the remote computing device 52. Additionally or alternatively, some remote operator user interfaces 32b may be hosted by the plant cloud component 50, and the remote computing device 52 may access the hosted remote user interfaces 32b, for example, as a website, a service, etc. The different operator interfaces 32a, 32b may be implemented by configuring selected generic structures 22a and generic functions 22b (e.g., by utilizing the set of APIs 20) based on information provided by the plant information model 18 to generate operator user interface views and functionality. In some scenarios, DCS 25 automatically generates, creates, and / or configures one or more operator interfaces 32 a, 32 b based on information stored in plant information model 18, as described in detail elsewhere in this disclosure. The configured operator interfaces 32 a, 32 b are stored in plant application library 40 for access by various components of DCS ecosystem 12, such as plant cloud component 50, local DCS operator interface 32 a, etc.

[0048] Support Engine Assistance engines 35 may include operator assistance engines 35a, 35b and control assistance engines 35c, 35d. Generally speaking, operator assistance engines 35a, 35b may monitor operator actions at DCS operator user interface 32 as the operator enters a series of queries and commands and may predictively alert the operator (e.g., visually and / or audibly via DCS operator user interface 32) if a set of actions the operator plans to take will result in a process outside the boundaries of acceptable operation and / or will generate an alarm, fault, or other undesirable condition. In some embodiments, operator assistance engines 35c, 35d may also provide additional information to assist the operator in determining and / or carrying out alternative or mitigating actions. For example, operator assistance engines 35a, 35b may alert the operator to a predicted flare, and operator assistance engines 35a, 35b may provide the operator with key factors contributing to the predicted flare and / or even specific mitigating actions for the operator to take, thereby preventing the flare from occurring. In some embodiments, the operator assistance engines 35c, 35d may initiate a dialogue with the operator (e.g., visually or audibly) to obtain additional information and better advise the operator on alternative or mitigation actions. In some circumstances, if the operator does not respond to an alert, the control assistance engines 35c, 35d may, for example, automatically execute at least some of the specific mitigation actions to bring the process to at least a safe operating state. The control assistance engines 35c, 35d (e.g., the availability of the control assistance engines 35c, 35d) may be activated or deactivated (e.g., individually or in groups). For some control assistance engines 35c, 35d, trigger conditions for executing automatic control assistance may be predefined (in some cases, the trigger conditions may be adjusted or modified). For example, trigger conditions may be defined to initiate various operator assistance functionality 35 based on a specific event, a specific condition, a specific risk level, a predicted impact, etc.

[0049] Automatically generated As indicated above, DCS 25 automatically generates and pre-configures at least a portion of plant information model 18, and in some embodiments also automatically generates additional control, I / O, HMI, and / or other functionality upon initialization, upon completion of physical connections to equipment located in industrial process plant 15, upon addition of another I / O port in DCS 25, upon placement of another additional device within physical plant 15, and / or in other scenarios. For example, when DCS 25 initializes or starts up, DCS 25 may automatically discover or sense the number and types of different physical I / O ports included in DCS 25. Based on the sensed I / O ports and their respective I / O types, DCS 25 may automatically generate representations of each of the sensed ports and their respective I / O types and store the generated representations in the description of the physical plant 15 (e.g., in the description of the physical plant 15 and / or the description of the control network) in plant information model 18 of data center 10, for example, by utilizing a common modeling language. DCS 25 may automatically generate representations of the sensed I / O ports and their respective I / O types using one or more readily available generic structures 22a corresponding to the I / O ports and / or I / O types. Furthermore, based on the sensed I / O types, DCS 25 may automatically generate one or more respective I / O data delivery mechanisms to support I / O data delivery to / from the sensed I / O ports. In some embodiments, at least some of the I / O data delivery mechanisms needed to support data delivery for the sensed I / O ports may already be readily available within DCS 25, e.g., as I / O data delivery functions included in generic framework 22. In some embodiments, DCS 25 may automatically generate additional I / O data delivery mechanisms to support data delivery for the sensed I / O ports by configuring and / or combining various readily available generic functions 22b. In embodiments, the automatically generated additional I / O data delivery mechanisms may be stored as applications 40.After DCS25 automatically generates one or more IO data delivery mechanisms, in one embodiment, DCS25 may instantiate the I / O data delivery mechanisms into corresponding I / O containers, which may be respectively allocated to one or more computing modules of I / O cluster 30 for activation (e.g., “spin-up”) and execution or operation during runtime operation of plant 15.

[0050] Additionally, DCS 25 may automatically discover any devices, instruments, and / or equipment of plant 15 that are communicatively connected to its I / O ports and may automatically generate and store their respective representations in plant information model 18. In an exemplary configuration, devices, instruments, and / or equipment of industrial process plant 15 may be physically connected to I / O ports of I / O cluster 30 via one or more high-speed Ethernet connections 60 (e.g., 100M Gigabit Ethernet, etc.), which may include Advanced Physical Layer (APL) transport technology supporting one or more protocols, which may enable intrinsically safe connectivity of field devices, other devices, various other instruments, and / or other equipment located in remote or hazardous locations, e.g., the field environment of process plant 15. Thus, DCS 25 may automatically discover devices (e.g., field devices, and optionally other devices, instruments, and / or equipment located in the field environment of plant 15) that are communicatively connected to its I / O ports using discovery mechanisms provided by one or more protocols supported by the APL of Ethernet connection 60. DCS 25 may generate and store representations of each of the sensed devices and / or equipment in plant information model 18 (e.g., within the description of the physical plant 15 and / or within the description of the control network) by utilizing a common modeling language. For example, DCS 25 may automatically generate representations of the sensed devices, instruments, and / or equipment by utilizing one or more readily available generic structures 22a corresponding to the devices, instruments, and / or equipment.

[0051] Based on the sensed I / O ports and connected devices of the plant 15, the DCS 25 may automatically generate control applications, control routines, control modules, control or function blocks, and / or control algorithms specific to the type of connected device. For example, different control routines, applications, modules, blocks, and / or algorithms may be generated for different field devices (such as actuators, sensors, measurement devices, etc.) by utilizing one or more readily available generic functions 22b associated with the process control functionality. Generally, as described above, a control routine or application may execute one or more different control modules, each of which may utilize a different control algorithm or logic to receive inputs from a runtime industrial process plant, make process control decisions based on the received inputs, generate process control signals for controlling other devices based on the decisions, and coordinate with control modules or blocks executing or executing in other process control devices (such as field devices), thereby controlling the runtime industrial process. For ease of reading herein, but not for purposes of limitation, the term “control routine” as used herein generally refers to a control routine and / or application, a control module, a control or function block, and / or a control module.

[0052] In some scenarios, the automatically generated different control routines may initially be configured with placeholders for specific logical control identifiers (e.g., device tags, data tags, and / or other types of logical control identifiers) of the associated devices and / or equipment. At some point during configuration of the DCS 25, a user may assign specific logical control identifiers to each device and / or equipment (e.g., via a configuration user interface of the DCS 25, not shown in FIG. 1 ), and the assigned control identifiers may replace or pre-populate the respective placeholders in the different control routines. In other scenarios, some of the sensed devices and / or sensed equipment themselves may have prior knowledge of one or more logical control identifiers by which they will each be identified to the control network of the plant 15 and may automatically provide those respective one or more logical control identifiers to the plant information model 18 during the discovery process. In these situations, the plant information model 18 may automatically include the respective provided control identifiers in the automatically generated different control routines corresponding to those devices / equipment. In yet another scenario, a mapping server (such as a DNS server) may provide the plant information model 18 with the respective logical control identifiers of various devices / equipment during a discovery process, and the plant information model 18 may automatically include the respective provided control identifiers in different automatically generated control routines corresponding to the various devices / equipment. In either case, the DCS 25 may store the generated control routines as applications 40, and the DCS 25 may store in the plant information model 18 (e.g., in the control strategy description and / or in the control network description) an indication of the logical control identifiers assigned to each device and / or equipment (e.g., by a user during configuration or previously as provided by the device, equipment, and / or mapping service).

[0053] Following DCS 25 automatically generating (and optionally pre-configuring with logical control identifiers) one or more control routines, DCS 25 may instantiate the one or more pre-configured control routines into corresponding control containers, which may be allocated to one or more computational modules of control cluster 28 for activation (e.g., “spin-up”) and execution or operation during runtime operation of plant 15.

[0054] Additionally, in embodiments, human-machine interface (HMI) graphics and / or display views (e.g., presented on one or more DCS operator interfaces 32) may also be automatically generated when the plant information model 18 is pre-populated with information. The DCS 25 may automatically generate HMI graphics and / or views based on the plant information model 18 by utilizing one or more readily available generic structures 22 a and / or functions 22 b of the data center 10. For example, the DCS 25 may automatically generate HMI graphics and / or display views specific to various types of sensed devices and / or sensed equipment, e.g., as the devices / equipment are sensed and added to the representation of the physical plant 15 in the plant information model 18. For example, the DCS 25 may automatically generate a temperature display view when a temperature sensor is discovered. Additionally or alternatively, DCS 25 may automatically generate HMI graphics and / or views specific to various types of control routines, for example, as the control routines are automatically generated and added to the control strategies stored in plant information model 18, and / or DCS 25 may automatically generate HMI graphics and / or views specific to various types of control-related functionality (e.g., alarms, warnings, safety algorithms / modules, etc.) as various devices, equipment, control routines, etc. are discovered and / or created. Further, in some implementations, more complex HMI graphics and / or views may be automatically generated, for example, based on multiple control routines, based on control routines and additional generic functions 22b, based on analysis performed on data generated by control components, etc. Generally speaking, HMI graphics and / or views may be automatically generated based on any information and / or combination of information stored in plant information model 18 of DCS 25.For some automatically generated HMI graphics and / or views, placeholders for logical identifiers of various devices, equipment, etc. may be initially utilized, with specific logical identifiers later being pre-populated (e.g., in a manner similar to that described above for control routines). For some automatically generated HMI graphics and / or views, the entire set of HMI graphics and / or views may be generated automatically without user input, e.g., based solely on information contained in plant information model 18, which may already be pre-populated with logical identifiers associated with the generated HMI graphics and / or views. In any event, once DCS 25 has automatically generated (and, if necessary, pre-configured) the set of HMI graphics and / or views, DCS 25 may instantiate the pre-configured set of HMI graphics and / or views, for example, as applications 40, as modules running on DCS operator user interface 32, and / or as HMI containers, which may each be allocated to one or more computing modules for execution / operation (e.g., in control cluster 28, in operator user interface 32, in other computing modules 31, in plant cloud computing components, and / or in any other suitable computing location within ecosystem 12).

[0055] Although the automatic generation of plant information model 18 and associated control and HMI functionality / applications has been discussed above with respect to the initialization or startup of DCS 25, those skilled in the art will understand that similar techniques may be applied after DCS 25 is initialized and changes to the physical configuration of DCS 25 and / or plant 15 occur, such as when additional physical I / O ports are added to DCS 25, when additional physical devices and / or equipment are added elsewhere within industrial process plant 15, etc.

[0056] Furthermore, while the automated generation of plant information model 18 and associated control and HMI functionality / applications has been discussed above with respect to connecting physical plant 15 to physical I / O ports of DCS 25 via one or more Ethernet transport media with an APL, those skilled in the art will appreciate that any or all of these techniques may be readily applied to other types of transport media that physically interconnect at least a portion of DCS 25 with physical industrial process plant 15, with or without I / O ports, and with or without APL. For example, Ethernet without an APL or a high-capacity packet network technology other than Ethernet may be used to physically connect at least a portion of industrial process plant 15 to DCS 25, e.g., to one or more I / O ports or to other types of interface ports of DCS 25, such as high-speed Ethernet ports. Indeed, in embodiments, numerous types of interconnection technologies may be used to interconnect physical industrial process plant 15 with DCS 25. For example, DCS 25 may connect to physical process plant 15 via Ethernet with I / O ports and APL, via I / O ports and non-Ethernet transport media, and via other types of interface ports and non-Ethernet transport mechanisms.

[0057] Furthermore, with regard to security, a chain of trust may be implemented within the components of industrial process plant ecosystem 12 from the initial startup of the computing modules supporting plant information model 18 through applications, devices, and / or nodes participating in ecosystem 12 to the final execution of the application itself. Additionally or alternatively, data center 10 may utilize one or more security applications or mechanisms to protect the contents of and / or access to the plant information model. For example, one or more security applications or mechanisms may be pre-provisioned or readily available in data center 10 and, therefore, stored in memory of data center 10 prior to initialization of data center 10.

[0058] Features, Applications, and Live Migration As mentioned above, the applications and functions 40a, 40b may be generated by utilizing one or more generic structures 22a and / or generic functions 22b, and some applications 40b may be generated further based on one or more third-party extensions 48. The applications / functions 40a, 40b may be stored in the plant application library 45. Some applications 40 may be automatically generated by the DCS 25, for example, by utilizing the generic framework 25 and the plant information model 18, and some applications 40 may be generated at least in part manually, for example, via an operator or user interface 32. Examples of possible applications may include an operator application, a configuration application, an I / O data distribution application, a search application, another type of user interface application, a process control application, a diagnostic application, an operator-facing assistance application, a control system-facing assistance application, a component verification application, a condition monitoring application, a remote monitoring application, a maintenance application, a descriptive analytics application, a predictive analytics application, a machine learning application, or a decision support application, to name a few. Additionally or alternatively, possible applications may include OT (operational technology) layer applications provided by the industrial distributed process control system, IT (information technology) layer applications provided by the process control system company, another type of application provided by the company, a user interface application, a cloud computing application, a decision support application, another type of analytical application, an application running on a mobile device, an application running on another system of the company, or an application provided by and running on a third-party system.

[0059] Instances of the applications 40a, 40b may be retrieved from the library 45 and executed on various components of the plant ecosystem 12, such as the control cluster 28, the I / O cluster 30, the DCS operator user interface 32a, as part of the assistance engine 35, and on the plant cloud computing component 50, and optionally on an associated remote user device 52. Similarly, although not shown, the generic function 22b may also be retrieved and executed on various components of the plant ecosystem 12.

[0060] Generally speaking, applications and functions 40 provided within plant ecosystem 12 may be packaged in a platform-neutral manner such that they are executable on numerous different types of operating systems, e.g., Windows®, Linux®, etc. Referring to control cluster 28 as an illustrative but non-limiting example of an execution environment within ecosystem 12, applications 40 and / or functions 22b may be packaged as respective containers (such as containers provided by DOCKER® computer software) or respective actors (such as actors provided by Akka.NET) assigned to run on control cluster 28. For example, control cluster 28 may execute or operate one or more control containers or actors, one or more alarm containers or actors, one or more safety containers or actors, etc. For ease of discussion, the entities into which applications and / or functions may be packaged are generally referred to herein as “containers,” although it will be understood that any suitable packing technique may be utilized to package applications and functions in a platform-neutral manner, including actors and / or other techniques.

[0061] Additionally, because the control cluster 28 includes multiple compute modules 26, each container assigned to the control cluster 28 may be further assigned to execute or operate on one or more specific compute modules of the control cluster 28. Accordingly, containers may be assigned to compute modules having available computing power and / or resources (in some cases, dynamically assigned or live migrated during runtime operation of the plant 15). Indeed, control-related containers need not be assigned to execute or operate only on compute modules of the control cluster 28, but may be assigned to execute or operate on any compute module of any cluster or processing environment provided by one or more components of the plant ecosystem 12 having available computing power and / or resources, such as the I / O cluster 30, the cluster supporting the DCS operator user interface 32a, the spare cluster 31, etc. Typically, but not necessarily, for at least security and performance reasons, applications 40 and / or functions 22b may be assigned to run on local computing modules, e.g., on computing modules of ecosystem components that are not located in cloud component 50 and / or otherwise remotely located from process plant 15 (e.g., at security level 2 or 3 of the Purdue Model). In one embodiment, the assignment and migration of applications 40 and / or functions 22b to various computing modules may be implemented by utilizing Software Defined Networking (SDN), Network Function Virtualization (NFV), and / or other technologies that allow the full stack of switches, address allocations, and routers to be completely defined in software.

[0062] Live migration or dynamic allocation of applications and / or functions (e.g., of the containers in which the applications and / or functions are respectively packaged or implemented) to respective compute modules may be triggered or otherwise performed automatically. For example, during runtime of the industrial process plant 15, the DCS 25 may monitor the available and / or utilized computing resources in each compute module and dynamically assign / reallocate applications and / or functions to other compute modules when conditions on the various compute modules change or are predicted to change. For example, the DCS 25 may reactively and / or proactively perform dynamic load balancing of compute modules used across or among multiple components of the ecosystem 12, such as leveling or balancing the load of all compute modules used in a particular component of the ecosystem 12, such as the control cluster 28 or the I / O cluster 30, and / or across both the control cluster 28 and the I / O cluster 30. In some situations, live migration or dynamic assignment of applications and / or functions (e.g., of the containers in which the applications and / or functions are respectively packaged or implemented) to respective compute modules may be triggered by manual operator action, such as when a particular compute module needs to be taken offline for scheduled maintenance and / or upgrade. For example, an operator may select a controller to take offline for scheduled maintenance and / or upgrade, and based on the operator selection, any applications and / or functions executing on the selected controller may be automatically live migrated to other compute modules (of control cluster 28, other components of DCS 25, or other components of ecosystem 12) for seamless continuation of execution, e.g., a “bumpless” transfer. Along with live migration, in embodiments, automatic load balancing of compute modules that remain in use may be automatically performed.

[0063] Indeed, the DCS 25 may provide bumpless transfer of functionality (and in particular, bumpless transfer of control and I / O functionality) so that the DCS 25 can maintain high availability during runtime of the industrial process plant 15. For example, the control cluster 28 may include backup controllers (which may be implemented via their respective applications and / or functions) in a one-to-one or one-to-many arrangement. When a switchover of control functionality from an active controller to a backup controller is required, the backup controller may be activated (e.g., one or more containers in which the backup controller functionality is packaged may be “spun up”) and synchronized with the active controller to provide live migration or bumpless transfer to the backup controller. Alternatively, in some situations, the backup controller may run in the background and track the runtime behavior of each active controller, thereby eliminating or minimizing synchronization when real-time control functionality is shifted from being provided by the active controller to being provided by the backup controller.

[0064] Pluggable DCS Hardware Modules In one embodiment, DCS 25 may be implemented using one or more universal (e.g., interchangeable), scalable, plug-and-play DCS hardware modules. A single universal, scalable, plug-and-play DCS hardware module may be utilized as a standalone unit to function as DCS 25, or may be combined with other universal, scalable, plug-and-play DCS hardware modules to scale up to a desired size (e.g., a desired capacity, performance level, set of functionality, etc.) of DCS 25. Such universal, scalable, plug-and-play DCS hardware modules are referred to interchangeably herein as “pluggable DCS hardware modules,” “pluggable DCS modules,” or “pluggable hardware modules.”

[0065] FIG. 2 illustrates a block diagram of an exemplary pluggable DCS hardware module 200. The pluggable DCS hardware module 200 may be included, for example, in the DCS 25 servicing or supporting the industrial process plant 15 of FIG. 1 , or may be included in another DCS servicing or supporting another industrial process plant. As shown in FIG. 2 , the pluggable DCS hardware module 200 is a hardware module that includes a physical housing 202 that encloses its internal components 205-230 that provide a standardized set of DCS interfaces, functionality, and features. However, in some embodiments of the pluggable DCS hardware module 200, the housing 202 may be omitted.

[0066] The example pluggable DCS hardware module 200 includes a standard set of interface ports 205a, 205b, 205n, at least some of which are configured to send and receive a standard set of I / O data types to and from the pluggable DCS hardware module 200. For example, the set of interface ports 205a-205n may include Ethernet APL ports and / or other types of ports that support the delivery of different types of I / O data to and from the field environment of an industrial process plant, such as analog I / O, discrete I / O, motion, NIR, serial, non-APL Ethernet, Wi-Fi, serial, Railbus, HART, WirelessHART, Fieldbus, Profibus, etc. The set of interface ports 205a-205n may support various transport media utilized within process control networks, such as two-wire and / or four-wire buses, optical links, wireless communications, high-speed Ethernet ports that support APL, Ethernet that does not support APL, etc. Generally speaking, the set of interface ports 205 is configured to support one or more industrial control protocols such as 4-20mA, Fieldbus, Profibus, HART, WirelessHART, HART-IP, OPC UA, etc. Additionally, the set of interface ports 205 of pluggable DCS hardware module 200 may include one or more network ports configured to support other types of common data and communication delivery protocols such as IP or other packet-based communication protocols, Wi-Fi, Bluetooth, etc., thereby enabling pluggable DCS hardware module 200 to communicatively connect to other pluggable DCS modules 200, industrial process plant 15 (or components thereof), and / or other systems and devices.

[0067] Exemplary pluggable DCS hardware module 200 also includes one or more processors 208 and one or more tangible, non-transitory memories 210. In one embodiment, pluggable DCS hardware module 200 comprises one or more computing modules including one or more processors 208 and one or more memories 210. Respective computer-executable instructions for data center 212, discovery engine 215, and execution engine 218 are pre-stored in one or more memories 210 of pluggable DCS hardware module 200. That is, data center 212, discovery engine 215, and execution engine 218 may be loaded or stored onto one or more tangible memories 210 of pluggable DCS hardware module 200 before pluggable DCS hardware module 200 is initially started up in the field at industrial process plant 15. 2, data center 212 includes a generic framework 220, a set of APIs 222, and storage for a plant information model 225 of an industrial process plant supported by pluggable DCS hardware modules 200. Data center 212 may be similar to data center 10 of FIG. 1, for example. Accordingly, generic framework 220 may include a standard set of generic structures and a standard set of generic functions, which may include control functions, I / O functions, HMI functions, and analytical functions. Set of APIs 222 may utilize a modeling language common to generic framework 220 and plant information model 225, and set of APIs 222 may be exposed for use by other applications.

[0068] Upon initialization of pluggable DCS hardware module 200, one or more processors 208 may execute computer-executable instructions included in discovery engine 215, causing DCS module 200 to automatically generate plant information model 225 that describes the industrial process plant supported by pluggable DCS hardware module 200. For example, discovery engine 215 may sense the number and types of I / O ports 205 included in pluggable DCS hardware module 200 and utilize API 222 and generic framework 220 to generate descriptions of the sensed I / O types and I / O ports, e.g., in a manner similar to that described above. Discovery engine 215 may pre-populate plant information model 225 with the generated descriptions of the sensed I / O types and I / O ports, e.g., by utilizing a common modeling language and, optionally, by utilizing some generic structures provided by generic framework 220.

[0069] Additionally, the discovery engine 215 may detect or discover a set of physical components or devices of the industrial process plant to which the pluggable DCS hardware module 200 is communicatively connected via the I / O ports 205, or upon connection of one or more I / O ports 205 to the industrial process plant. For example, for a sensed APL port, the discovery engine 215 may utilize packet protocol discovery mechanisms to discover one or more devices communicatively connected to the pluggable DCS hardware module 200 via the APL port. Discovered or discovered devices may typically include various field devices, such as actuators, sensors, measurement devices, pumps, heaters, etc., that are physically located within the industrial process plant and utilized by the plant to perform physical functions to control the industrial process. In some configurations, discovered or discovered devices may include physical industrial controllers, such as process controllers or safety controllers. In some configurations, discovered or discovered devices may include I / O devices, such as I / O cards and / or I / O marshalling cabinets. In some arrangements, the discovered or detected devices may further include networking devices such as routers, adapters, etc. Indeed, in some embodiments, the discovered or detected devices may include devices of other systems associated with the industrial process plant, such as asset management systems, analytical systems, etc. Such other systems may typically be at a similar level of security as pluggable DCS hardware module 200 (e.g., Purdue Model Level 3 or 4), although this is not required.

[0070] In any event, discovery engine 215 may utilize API 222 and generic framework 220 to generate descriptions of detected or discovered physical devices within the physical plant description of plant information model 225 and, if appropriate, within the control strategy / control framework description and / or control network description of plant information model 225, e.g., in a manner similar to that described elsewhere in this disclosure. Thus, discovery engine 215 pre-populates plant information model 225 with physical descriptions and optionally logical descriptions of the detected or discovered physical devices. For example, for discovered field devices, discovery engine 215 pre-populates plant information model 225 with a physical description of each of the field devices, a logical description of each of the field devices as control components of the plant, and a description of the field device in relation to other control network components of the plant.

[0071] The discovery engine 215 may automatically generate respective types of control routines based on the types of discovered devices, e.g., in a manner similar to that described elsewhere in this disclosure. For example, different control routines may be generated for different field devices (actuators, sensors, measurement devices, etc.) by utilizing one or more readily available generic functions (e.g., of the generic framework 220) associated with the process control functionality. In some scenarios, the discovery engine 215 may also automatically generate respective HMI / display views corresponding to the discovered devices, e.g., in a manner such as those described above. The generated control routines and generated HMI / display views may be stored in the memory 210 of the pluggable DCS hardware module 200. During runtime operation of the industrial process plant, the processor 208 of the pluggable DCS hardware module 200 may execute computer-executable instructions contained in the execution engine 218 to execute control routines, HMI / display views, various generic functions, and / or other applications and / or functionalities stored in the memory 210 of the pluggable DCS hardware module 200, thereby controlling the plant's industrial processes and providing other functionality related to the control and operation of the industrial process plant.

[0072] Of course, in addition to performing discovery actions upon initialization of pluggable DCS hardware module 200, discovery engine 215 may be triggered to perform discovery actions at other times during runtime of the industrial process plant. For example, if discovery engine 215 senses during runtime that an additional interface port has been added to pluggable DCS hardware module 200, discovery engine 215 may initiate discovery logic to add a description of the additional interface port and any devices communicatively connected to pluggable DCS hardware module 200 via that additional interface port. Similarly, if discovery engine 215 discovers or detects during runtime that an additional device has been added (e.g., via an already-sensed interface port), discovery engine 215 may initiate discovery logic to add a description of the additional device and a description of any control strategy associated with that type of device, e.g., in a manner similar to that described above.

[0073] Thus, in some implementations, a single pluggable DCS hardware module 200 may be immediately usable and self-configure upon initialization to function as a DCS (e.g., DCS 25) for a smaller industrial process plant. If desired, additional I / O ports may be added to the single pluggable DCS hardware module 200 to provide additional numbers and / or types of I / O interfaces, up to a limit. Additionally or alternatively, if desired, additional compute modules may be added to the single pluggable DCS hardware module 200 to provide, for example, additional computing resources, up to a limit. Generally speaking, the maximum size of a single pluggable DCS hardware module 200 is limited by the hardware, e.g., the physical dimensions of the housing 202, the number of possible physical ports 205, the number of possible connections for additional compute modules, etc.

[0074] Advantageously, in other situations, multiple pluggable DCS modules 200 may be interconnected to collectively function as a DCS (e.g., DCS 25) for a larger industrial process plant. In these larger configurations, each pluggable DCS hardware module 200 may discover, via its respective discovery engine 215, the other pluggable DCS modules 200 to which it is communicatively connected, and the respective devices disposed within the industrial process plant that are communicatively connected to each of the pluggable DCS modules 200. For example, a first pluggable DCS hardware module 200 may discover a second pluggable DCS hardware module 200 upon initialization. Alternatively, after the first pluggable DCS hardware module 200 is initialized and configured, the first pluggable DCS hardware module 200 may discover the second pluggable DCS hardware module 200 upon establishment of a communication connection between the first and second pluggable DCS modules. In one embodiment, the multiple pluggable DCS modules 200 may operate, in a sense, as a set of individual switches networked together, each utilizing its own computing and hardware resources to manage a set of devices in the industrial process plant communicatively connected via its I / O ports. In another embodiment, the multiple pluggable DCS modules 200 may collectively operate as a single logical DCS 25, such as DCS 25 of FIG. 1, sharing computing and hardware resources to collectively manage all of the devices in the industrial process plant communicatively connected to the logical DCS 25 via the various I / O ports of the various modules 200. Of course, hybrid implementations including both individual and collective module management are also possible.

[0075] As described above, during runtime of an industrial process plant to which pluggable DCS hardware module 200 is communicatively connected, one or more processors 208 of hardware module 200 may execute computer-executable instructions contained in execution engine 218, causing DCS hardware module 200 to control at least a portion of the industrial process of the industrial process plant. In particular, pluggable DCS hardware module 200 may include one or more control routines 228 and one or more I / O data delivery mechanisms stored in one or more memories 210, each of which may be executable by one or more processors 208, for example, via execution engine 218. Of course, other runtime routines and algorithms (not shown), such as generic functions of generic framework 220, various support functions, routines, algorithms, and / or applications such as HMI / display views, diagnostics, analytics, etc., may additionally or alternatively be executed by one or more processors 208 via execution engine 218.

[0076] In any event, using an exemplary scenario, pluggable DCS hardware module 200 may be communicatively connected to field devices located within a process plant's field environment, for example, via a particular interface port 205a. Via discovery engine 215, plant information model 225 may use a modeling language to sense, discover, generate, and store descriptions of control loops that include field devices, interface ports 205a, and particular control routines 228. In one embodiment, particular control routines 228 may be automatically generated based on one or more generic control functions included in generic framework 220, such as in a manner similar to that described above. Furthermore, as previously described, via discovery engine 215, interface ports 205a may be bound to particular I / O data delivery mechanisms 230. Thus, during runtime of the industrial process plant, execution engine 218 may cause particular control routines 228 and particular I / O data distribution mechanisms 230 to execute in pluggable DCS hardware modules 200 to distribute process data between control routines 228 and field devices, thereby executing the control loops described in plant information model 225 and thereby controlling the industrial process. In one embodiment, control routines 228 may execute or operate on a cluster of control computing modules of pluggable DCS hardware modules 200, such as control cluster 28 of FIG. 1 , and / or I / O data distribution mechanisms may execute or operate on a cluster of I / O computing modules of pluggable DCS hardware modules 200, such as, for example, I / O cluster 30 of FIG. 1 .

[0077] Figure 3 shows a block diagram of an example method 300 for automatically initializing an industrial distributed process control system (DCS) of a physical industrial process plant, such as physical process plant 15 of Figure 1. In an embodiment, at least a portion of method 300 may be performed by DCS 25 of Figure 1 and / or at least a portion of method 300 may be performed by one or more pluggable, replaceable DCS hardware modules 200 of Figure 2. In an embodiment, method 300 may include additional or alternative blocks other than those discussed within this disclosure.

[0078] An industrial distributed process control system initialized by the exemplary method 300 includes a set of one or more pluggable, replaceable DCS hardware modules, such as one or more DCS hardware modules 200. Generally speaking, a respective instance of method 300 may be performed by each DCS hardware module in the set.

[0079] At block 302, method 300 includes automatically detecting or sensing, in a pluggable DCS hardware module of a set of pluggable DCS hardware modules included in a DCS, a respective I / O type of each interface port of a plurality of interface ports included in the pluggable DCS hardware module. The respective I / O types of the interface ports may be detected or sensed upon power-on or restart of the pluggable DCS module and / or when additional interface ports are added to the pluggable DCS hardware module 302. The “I / O type” of an interface port, as used herein, may refer to different types of I / O data delivered through the interface port, different types of transport mechanisms and / or media supported by the interface port, different types of data protocols utilized to deliver the I / O data through the interface port, etc. Thus, exemplary I / O types of interface ports may include analog I / O, discrete I / O, serial, motion, near infrared, Railbus, Wi-Fi, Ethernet without an Advanced Physical Layer, Ethernet with an Advanced Physical Layer, HART, WirelessHART, Fieldbus, and Profibus, to name a few, although other I / O types of interface ports are possible.

[0080] At block 305, method 300 includes binding, by each pluggable DCS hardware module, to each interface port a respective I / O data distribution mechanism corresponding to each I / O type of each interface port. Generally speaking, during runtime operation of the plant, each I / O data distribution mechanism may translate (if necessary) I / O data received via the interface port and distribute the received I / O data to applications, such as control routines, executing on the pluggable DCS hardware module. Similarly, during runtime operation of the plant, each I / O data distribution mechanism may translate data received from the control routines and distribute the translated data via their respective interface ports to devices located in the industrial process plant.

[0081] At block 308, the method 300 includes automatically discovering, by each pluggable DCS hardware module, one or more physical components of the industrial process plant to which each pluggable DCS hardware module is communicatively connected via a plurality of interface ports. The one or more physical components include field devices communicatively connected to each pluggable DCS hardware module via respective interface ports, the field devices configured to perform physical functions to control the industrial process during runtime operation of the industrial process plant. In some configurations, the one or more physical components include physical process controllers and / or physical safety controllers. In some embodiments, the one or more physical components include physical I / O devices disposed between the respective interface ports and the field devices, thereby enabling the field devices and control routines to communicate process data to control the industrial process during runtime.

[0082] In example scenarios involving automatic discovery 308, method 300 may further include detecting that a particular physical component has been newly connected (e.g., communicatively connected) to the pluggable DCS hardware module via at least one of the plurality of interface ports, such as when an additional field device is added to the plant and powered on. In these scenarios, method 300 may include automatically initiating discovery of the newly connected particular component upon detection of a new communication connection to the pluggable DCS hardware module (block 308).

[0083] At block 310, method 300 includes automatically pre-configuring at least a portion of a plant information model of the DCS, such as plant information model 18,225, based on discovery of one or more physical components by each pluggable DCS hardware module. The plant information model includes a description of the control framework of the industrial process plant and a description of the control network utilized to control the industrial process during runtime operation of the industrial process plant, both descriptions being expressed or defined within the plant information model using a common or same modeling language. The control framework defines logical control identifiers for each of the control components of the DCS and hierarchical relationships among the control components, including field devices. The control network includes the field devices, their respective interface ports, control routines provided by each pluggable DCS hardware module, and other control components (and, optionally, network components) utilized for process control of the industrial process plant. Thus, once pre-configured, the plant information model stores and utilizes descriptions of control loops and other control-related components, entities, and combinations / groupings thereof to control the industrial process within the industrial process plant.

[0084] In some embodiments, the plant information model further includes a description of one or more physical components to which the pluggable DCS hardware modules are communicatively connected, their respective locations within the industrial process plant, and the respective interconnections between the one or more physical components. Generally, the one or more physical components are located within the field environment of the industrial process plant, although in some configurations, at least one physical component may be located elsewhere, such as in a back-end or remote environment of the industrial process plant. In any event, the plant information model may represent or define a description of the one or more physical components and associated locations and interconnections of the industrial process plant by using a common or same modeling language used to represent the control framework and control network of the industrial process plant.

[0085] In some embodiments, a set of application programming interfaces (APIs) is provided with the plant information model. The set of APIs may be exposed to functions and applications so that the functions and applications may access the information stored in the plant information model. Thus, the set of APIs may be implemented using the same or a common modeling language as that used to define or represent the information stored in the plant information model.

[0086] At block 312, method 300 includes executing, by each pluggable DCS hardware module, a control routine bound to a respective interface port and a respective I / O data distribution mechanism to distribute data between the field device and the control routine during runtime operation of the industrial process plant, thereby controlling the industrial process. That is, block 312 includes executing, during runtime of the industrial process plant, a control loop including the field device, the respective interface port, and the control routine to thereby control the industrial process.

[0087] In some embodiments, the DCS includes an initial set of control functions stored in the memory of a set of pluggable DCS hardware modules prior to initialization or power-on of the DCS. The initial set of control functions may include, for example, adaptive control functions, event-based control functions, advanced control functions, regulatory control functions, batch control functions, sequencing functions, interlock functions, safety shutdown functions, condition detection functions, real-time virtualization controllers, and / or backup virtualization controllers. In these embodiments, the method 300 may include automatically generating control routines corresponding to field devices (and / or automatically generating other control routines executed by the DCS) based on the initial set of control functions and the plant information model (not shown in FIG. 3 ). For example, various initial control functions may be configured in combination with logical control identifiers, parameters, and values ​​from the plant information model to generate the control routines.

[0088] The DCS may assign various control routines that it automatically generates to execute on each pluggable DCS hardware module. For example, the DCS may package a particular control routine into a container and assign the container to run on a particular pluggable DCS hardware module. Alternatively, an instance of a control routine may be provided to a particular pluggable DCS hardware module for execution. During runtime operation of the industrial process plant, the DCS may reallocate the assignment of control routines or containers to each pluggable DCS hardware module automatically based on, for example, changes in the load, size, performance metrics, and / or faults of one or more of the DCS hardware modules in the set. The changes may be, for example, detected changes or predicted changes. In this manner, advantageous features such as automatic load balancing and / or live migration of various control routines across a set of DCS hardware modules may be achieved.

[0089] In some embodiments, the DCS includes an initial set of I / O data distribution functions stored in memory of a set of pluggable, interchangeable DCS hardware modules prior to initialization or power-on of the DCS. The initial set of I / O data distribution functions may include, for example, analog I / O functions, discrete I / O functions, motion I / O functions, near-infrared (NIR) I / O functions, other types of I / O transport functions, sampling functions, and / or signal conditioning functions. In these embodiments, the method 300 may include automatically generating at least a portion of the respective I / O data distribution mechanisms corresponding to the interface ports of various pluggable DCS hardware modules of the DCS based on the initial set of I / O data distribution functions and the plant information model (not shown in FIG. 3 ). For example, the various initial I / O data distribution functions may be configured in combination with logic control identifiers, parameters, and values ​​from the plant information model to generate the I / O data distribution mechanisms.

[0090] The DCS may assign various I / O data delivery mechanisms that it automatically creates to run on each pluggable DCS hardware module. For example, the DCS may package a particular I / O data delivery mechanism into a container and assign the container to run on a particular pluggable DCS hardware module. Alternatively, an instance of an I / O data delivery mechanism may be provided for execution on a particular pluggable DCS hardware module. The DCS may reallocate the assignment of I / O data delivery mechanisms or containers to each pluggable DCS hardware module during runtime operation of the industrial process plant automatically based on, for example, changes in the load, size, performance metrics, and / or failures of one or more of the DCS hardware modules in the set. The changes may be, for example, detected changes or predicted changes. In this manner, advantageous features such as automatic load balancing across a set of DCS hardware modules and / or live migration of various I / O data delivery mechanisms may be achieved.

[0091] In some embodiments (not shown in FIG. 3 ), the DCS includes an initial set of support functions stored in memory of a set of pluggable DCS hardware modules prior to initialization or power-on of the DCS. The initial set of support functions may include functions that are not directly utilized in process control but may otherwise operate on data generated by the industrial process plant during runtime process control to generate outputs that may provide information and / or influence various control routines. Examples of support functions include, but are not limited to, signal processing functions, alarm functions, history functions, trend functions, diagnostic functions, descriptive analytics functions, predictive analytics functions, machine learning functions, reinforcement learning functions, bus functions, and user interface functions. In these embodiments, the method 300 may include automatically generating additional support functions based on the initial set of support functions and the plant information model (not shown in FIG. 3 ). For example, trend functions, alarm functions, and user interface functions may be combined to generate additional support functions to monitor the outputs of various control components defined in the plant information model. In some arrangements, the outputs of the initial support functions and / or the outputs of the additional, automatically generated support functions may be provided as inputs to the control routine runtime operation of the industrial process plant, thereby directly affecting the behavior of the process control. For example, an analysis routine may, upon reaching a certain threshold, generate control signals that are provided to one or more control routines to automatically adjust the process.

[0092] Any or all of the initial set of control functions, the initial set of I / O delivery mechanisms, and the initial set of support functions may be pre-stored in a set of pluggable DCS hardware modules, e.g., prior to initialization of the DCS and / or each pluggable DCS hardware module. For example, the initial set of control functions, the initial set of I / O data delivery mechanisms, and the initial set of support functions may be stored in a generic framework of the DCS, such as generic framework 22 of FIG. 1 or generic framework 220 of FIG. 2. Additionally, a set of application programming interfaces (APIs) may be provided by pluggable DCS hardware module 200 and exposed to other functions and applications, thereby allowing other functions and applications to access the initial set of control functions, I / O data delivery mechanisms, and / or support functions. In one embodiment, the set of APIs utilized to access the generic framework may be the set of APIs utilized to access the plant information model. Thus, the set of APIs may be implemented using the same or a common modeling language used to define or represent information stored in the plant information model. For example, the set of APIs can be a set of APIs 20 or 222.

[0093] The set of functions and applications of the DCS that are provided with access to the plant information model and / or generic framework may include, for example, one or more of discovery engine 215, execution engine 218, control routine 228, or I / O data distribution mechanism 230 of FIG. 2 , and / or any routines, mechanisms, algorithms, containers, etc. operating or executing on control cluster 28, I / O cluster 30, and / or other compute cluster 31 of FIG. 1 . In some configurations, the DCS further includes one or more security applications that protect the contents of and / or access to the plant information model. Typically, such security applications may be stored in memory of the set of pluggable DCS hardware modules prior to initialization or power-on of the DCS and / or each pluggable DCS hardware module. In some embodiments, the applications and functions of the DCS that are provided with access to the plant information model and / or generic framework may include, for example, operator assistance engine and / or control assistance engine 35. Additionally or alternatively, the set of functions and applications of the DCS that are provided with access to the plant information model and / or generic framework may include applications and functions 40 stored in a plant application library, such as library 45, and the applications stored in the plant application library may include applications automatically generated by the DCS (e.g., in the manner described above), applications manually generated via user interfaces 32a, 52, applications that include third-party extensions 40b, etc.

[0094] As described above, in embodiments, a DCS may include multiple pluggable, interchangeable DCS hardware modules. Accordingly, in those embodiments relating to automatic discovery 308, method 300 may further include, upon establishment of a communication connection between the first pluggable DCS hardware module and the second pluggable DCS hardware module, detecting a second pluggable DCS hardware module of the DCS by the first pluggable DCS hardware module. In these configurations, multiple pluggable DCS hardware modules may cooperate to store information, data, functionality, etc., in a distributed manner among the multiple pluggable DCS hardware modules. For example, the multiple pluggable DCS hardware modules may store, in a distributed manner among their respective memories, a plant information model, a generic framework, a set of APIs exposed to applications and functions, one or more control routines, one or more I / O distribution mechanisms, a plant application library, one or more applications (e.g., operator interfaces, assistance engines, etc.), etc. However, not all information needs to be stored in a distributed or non-distributed manner. In an exemplary configuration, a plant information model may be stored in a first pluggable DCS module, a backup copy of the plant information model may be stored in a second pluggable DCS module, instances of some control routines may be stored in more than one pluggable DCS module, and operator interface applications may be stored distributed across the set of pluggable DCS modules. Additionally, the DCS (e.g., via one or more pluggable DCS hardware modules) may automatically redistribute allocations of information, data, functionality, applications, etc. among the set of DCS pluggable hardware modules in response to changes in one or more DCS pluggable hardware modules, such as changes in load, size, or performance metrics, the occurrence of a fault, planned maintenance, etc. The DCS may perform the automatic redistribution based, for example, on predicted or detected changes.

[0095] If implemented in software, any of the applications, modules, etc. described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state storage device, molecular memory storage device, or other storage medium, RAM, or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed as including software and / or firmware running on hardware, among other components, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the exemplary systems described herein are described as implemented in software running on processors of one or more computing devices, those skilled in the art will readily recognize that the provided examples are not the only way to implement such systems.

[0096] Thus, while the present invention has been described with reference to specific examples, it will be apparent to those skilled in the art that these are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0097] The particular features, structures, and / or characteristics of any particular embodiment may be combined with one and / or more other embodiments in any suitable manner and / or in any suitable combination, including using selected features with or without the corresponding use of other features. Furthermore, many modifications may be made to adapt a particular application, situation, and / or material to the essential scope or spirit of the invention. It should be understood that other variations and / or modifications of the embodiments of the invention described and / or illustrated herein are possible in light of the teachings herein and should be considered part of the spirit or scope of the invention. Certain aspects of the invention are described herein as exemplary aspects.

Claims

1. 1. An industrial distributed process control system (DCS) for an industrial process plant, the industrial distributed process control system comprising a set of pluggable and replaceable DCS hardware modules, each pluggable and replaceable DCS hardware module of the set comprising: a plurality of interface ports configured to deliver one or more types of input / output (I / O) data utilized in industrial process control; one or more processors; one or more tangible non-transitory memories; a discovery engine including first computer-executable instructions stored in the one or more tangible, non-transitory memories, the instructions, when executed by the one or more processors, automatically causing each of the pluggable, replaceable DCS hardware modules to: sensing an I / O type of each interface port included in the plurality of interface ports upon power-on of each of the pluggable replaceable DCS hardware modules; binding a respective I / O data delivery mechanism corresponding to each of the I / O types to each of the interface ports; discovering one or more physical components of the industrial process plant to which each pluggable interchangeable DCS hardware module is communicatively connected via the plurality of interface ports, the one or more physical components including field devices configured to perform physical functions to control an industrial process during runtime operation of the industrial process plant; pre-configuring at least a portion of a plant information model of the DCS based on the discovery of the one or more physical components, the plant information model comprising: a description of a control framework for the industrial process plant, the control framework defining logical control identifiers for each of the control components of the DCS and hierarchical relationships between the control components, the control components including the field devices; and a discovery engine that causes the pre-configuration of the industrial process plant, the discovery engine including a description of a control network of the industrial process plant that is utilized to control the industrial process during the runtime operation of the industrial process plant, the control network including the field devices, the respective interface ports through which the field devices are communicatively connected to each of the pluggable interchangeable DCS hardware modules, and the control routines provided on each of the pluggable interchangeable DCS hardware modules; an execution engine including second computer-executable instructions stored in the one or more tangible, non-transitory memories, which, when executed by the one or more processors, cause each of the pluggable, interchangeable DCS hardware modules to execute the control routine and cause each of the I / O data delivery mechanisms bound to the respective interface ports to deliver data between the field devices and the control routine, thereby controlling the industrial process.

2. The industrial distributed process control system of claim 1 , wherein each pluggable, replaceable DCS hardware module of the set of pluggable, replaceable DCS hardware modules is enclosed in a respective housing.

3. 3. The industrial distributed process control system of claim 1, wherein each pluggable, interchangeable DCS hardware module is configured to detect when a particular physical component of the one or more physical components is newly communicatively connected to the respective pluggable, interchangeable DCS hardware module via at least one of the plurality of interface ports, and discovery of the particular physical component is automatically initiated by the DCS based on the detection of the new communication connection.

4. 4. The industrial distributed process control system of claim 1, wherein the plurality of interface ports comprises at least one of an Advanced Physical Layer port, an analog I / O port, a discrete I / O port, a serial port, a motion port, a near-infrared port, a Railbus port, a Wi-Fi port, an Ethernet port, a HART port, a WirelessHART port, a Fieldbus port, a Profibus port, or another type of interface port.

5. The industrial distributed process control system of any one of claims 1 to 4, wherein the one or more discovered physical components include at least one physical process controller.

6. the DCS further includes an initial set of control functions stored in the one or more tangible, non-transitory memories of the set of pluggable, replaceable DCS hardware modules prior to initialization of the DCS; 6. The industrial distributed process control system of claim 1, wherein the DCS is configured to automatically generate the control routines corresponding to the field devices based on one or more control functions included in the initial set of control functions and the plant information model.

7. 7. The industrial distributed process control system of claim 6, wherein the set of pluggable, interchangeable DCS hardware modules is a plurality of pluggable, interchangeable DCS hardware modules, and the DCS is further configured to automatically assign the control routine to run on a particular pluggable, interchangeable DCS hardware module of the plurality of pluggable, interchangeable DCS hardware modules.

8. 8. The industrial distributed process control system of claim 7, wherein the control routines are packaged within containers that are assigned to run on the particular pluggable, replaceable DCS hardware module.

9. 10. The industrial distributed process control system of claim 8, wherein the DCS is further configured to automatically reallocate the container in which the control routine is packaged to run on another pluggable replaceable DCS hardware module based on a change in at least one of load, size, performance metrics, or failure of at least one of the pluggable replaceable DCS hardware modules.

10. The industrial distributed process control system of claim 9 , wherein the change is a predicted change.

11. 11. The industrial distributed process control system of claim 6, wherein the initial set of control functions includes one or more of an adaptive control function, an event-based control function, an advanced control function, a regulatory control function, a batch control function, a sequencing function, an interlock function, a safety shutdown function, a condition detection function, a real-time virtualization controller, or a backup virtualization controller.

12. 12. The industrial distributed process control system of claim 1, wherein the discovered one or more physical components further include physical I / O devices disposed between the respective interface ports and the field devices, and the field devices communicate process data with the control routine to control the industrial process during the runtime operation via the physical I / O devices.

13. the DCS further includes an initial set of I / O data delivery functions stored in the one or more tangible, non-transitory memories of the set of pluggable, replaceable DCS hardware modules prior to initialization of the DCS, the initial set of I / O data delivery functions including one or more of analog I / O functions, discrete I / O functions, motion I / O functions, near-infrared (NIR) I / O functions, another type of I / O transport functions, sampling functions, or signal conditioning functions; The industrial distributed process control system of any one of claims 1 to 12, wherein the respective I / O data delivery mechanisms are based on the initial set of I / O data delivery functions.

14. 14. The industrial distributed process control system of claim 13, wherein the DCS is configured to automatically generate at least a portion of the respective I / O data delivery mechanisms corresponding to the plurality of interface ports based on the initial set of I / O data delivery capabilities and the sensed I / O types corresponding to the set of pluggable, replaceable DCS hardware modules.

15. 15. The industrial distributed process control system of claim 14, wherein the set of pluggable, interchangeable DCS hardware modules is a plurality of pluggable, interchangeable DCS hardware modules, and the DCS is further configured to automatically allocate the generated at least some of the respective I / O data delivery mechanisms to run on the respective pluggable, interchangeable DCS hardware modules.

16. 16. The industrial distributed process control system of claim 15, wherein the generated at least some of the respective I / O data delivery mechanisms are packaged in respective containers that are assigned to run on the respective pluggable replaceable DCS hardware modules.

17. 17. The industrial distributed process control system of claim 15 or 16, wherein the DCS is further configured to reallocate one or more assignments of the generated at least some of the respective I / O data delivery mechanisms to different pluggable replaceable DCS hardware modules based on a change in at least one of load, size, performance metrics, or failure of at least one of the pluggable replaceable DCS hardware modules.

18. the DCS further includes an initial set of support functions stored in the one or more tangible, non-transitory memories of the set of pluggable, replaceable DCS hardware modules prior to initialization of the DCS; each support function of the initial set of support functions operates on at least a portion of the data generated by the set of pluggable, interchangeable DCS hardware modules during the runtime operation of the industrial process plant; 18. The industrial distributed process control system of claim 1, wherein the initial set of support functions includes at least one of a signal processing function, an alarm function, a history function, a trend function, a diagnostic function, a descriptive analysis function, a predictive analysis function, a machine learning function, a reinforcement learning function, a bus function, or a user interface function.

19. 20. The industrial distributed process control system of claim 18, further comprising a support function generation routine stored in the one or more tangible, non-transitory memories of the set of pluggable, replaceable DCS hardware modules, the support function generation routine automatically generating additional support functions based on the initial set of support functions and the plant information model.

20. 20. The industrial distributed process control system of claim 18 or 19, wherein the control routine is configured to receive as input at least one of an output of at least one of the initial set of support functions or an output of an additional support function generated based on the initial set of support functions and the plant information model.

21. 21. The industrial distributed process control system of claim 1, further comprising a set of application programming interfaces (APIs) exposed to a set of applications, said set of APIs providing said set of applications with access to said plant information model.

22. 22. The industrial distributed process control system of claim 21, wherein the set of applications is stored in an application library of the DCS, wherein respective instances of at least some of the set of applications reside on a cloud computing component corresponding to the industrial process plant, and wherein the respective instances of the at least some of the set of applications that reside on the cloud computing component are accessible to one or more remote user interfaces associated with the DCS.

23. a first application of the set of applications is provided by a third party; or 23. The industrial distributed process control system of claim 21 or 22, wherein a second one or more applications of the set of applications are provided by or at least one of the industrial distributed process control system, and the second one or more applications include at least one of an operator application, a configuration application, an I / O data distribution application, a search application, another type of user interface application, a process control application, a diagnostic application, an operator-facing assistance application, a control system-facing assistance application, a component verification application, a condition monitoring application, a remote monitoring application, a maintenance application, a descriptive analytics application, a predictive analytics application, a machine learning application, or a decision support application.

24. 24. The industrial distributed process control system of claim 21, wherein the set of applications includes at least one of an OT (operational technology) layer application provided by the industrial distributed process control system, an IT (information technology) layer application provided by an enterprise of the process control system, another type of application provided by the enterprise, a user interface application, a cloud computing application, a decision support application, another type of analytical application, an application running on a mobile device, an application running on another system of the enterprise, or an application provided by and running on a third party system.

25. 25. The industrial distributed process control system of claim 1, wherein the plant information model further comprises a description of the one or more physical components of the industrial process plant, a description of respective locations within the industrial process plant at which the one or more physical components are each located, and a description of respective interconnections between the one or more physical components.

26. the plant information model stores information using a modeling language, the information including the control framework description and the control network description; 26. The industrial distributed process control system of claim 1, wherein a set of application programming interfaces (APIs) provides a set of applications of the DCS with access to the information stored in the plant information model by utilizing the modeling language.

27. 27. The industrial distributed process control system of claim 26, wherein the plant information model further stores, using the modeling language, a description of the one or more physical components of the industrial process plant, a description of respective locations within the industrial process plant at which each of the one or more physical components is located, and a description of respective interconnections between the one or more physical components.

28. 28. The industrial distributed process control system of claim 26 or 27, wherein the modeling language includes abstractions of data provided to the plant information model by different data sources, each utilizing a different data format.

29. 30. The industrial distributed process control system of claim 28, wherein the different data sources include at least one of at least one discovered physical component, a configuration database of the industrial process plant, or an asset management database of the industrial process plant.

30. 30. The industrial distributed process control system of claim 1, further comprising one or more security applications stored with the plant information model, the one or more security applications protecting at least one of the contents of the plant information model or access to the contents of the plant information model.

31. 31. The industrial distributed process control system of claim 1, wherein the set of pluggable, interchangeable DCS hardware modules includes multiple pluggable, interchangeable DCS hardware modules, and wherein the discovery engine of a first pluggable, interchangeable DCS hardware module of the multiple pluggable, interchangeable DCS hardware modules automatically discovers a second pluggable, interchangeable DCS hardware module of the multiple pluggable, interchangeable DCS hardware modules upon establishment of a communication connection between the first and second pluggable, interchangeable DCS hardware modules.

32. 32. The industrial distributed process control system of claim 31 , wherein at least one of (i) the plant information model or (ii) a set of application programming interfaces (APIs) exposed to a set of applications to provide the set of applications with access to the plant information model is stored in a distributed manner among the one or more tangible, non-transitory memories of the multiple pluggable, interchangeable DCS hardware modules.

33. 33. The industrial distributed process control system of claim 32, wherein the DCS is further configured to automatically reallocate storage distribution of the at least one of the plant information model or the set of APIs among the multiple pluggable interchangeable DCS hardware modules in response to a change to at least one of load, size, performance metrics, or failures corresponding to at least one of the multiple pluggable interchangeable DCS hardware modules.

34. 34. The industrial distributed process control system of claim 33, wherein the change is a predicted change or a detected change.

35. 31. The industrial distributed process control system of claim 1, wherein the set of pluggable, replaceable DCS hardware modules includes only a single pluggable, replaceable DCS hardware module, and the entire plant information model is stored on the one or more tangible, non-transitory memories of the single pluggable, replaceable DCS hardware module.

36. The industrial distributed process control system of any one of claims 1 to 35, wherein a total number of pluggable replaceable DCS hardware modules in the set of pluggable replaceable DCS hardware modules is in accordance with a desired size of the DCS.

37. 37. The industrial distributed process control system of claim 1, wherein the industrial distributed process control system is scalable by at least one of adding additional pluggable, replaceable DCS hardware modules or removing existing pluggable, replaceable DCS hardware modules.

38. 1. A method of initializing an industrial distributed process control system (DCS) for an industrial process plant, the industrial distributed process control system including a set of pluggable, replaceable DCS hardware modules, the method comprising: sensing, by each pluggable and interchangeable DCS hardware module upon power-on of each pluggable and interchangeable DCS hardware module, a respective I / O type of each interface port included in a plurality of interface ports included in each pluggable and interchangeable DCS hardware module; binding a respective I / O data delivery mechanism corresponding to each of the I / O types to each interface port by each of the pluggable replaceable DCS hardware modules; discovering, by each pluggable, interchangeable DCS hardware module, one or more physical components of the industrial process plant to which each pluggable, interchangeable DCS hardware module is communicatively connected via the plurality of interface ports, the one or more physical components including field devices communicatively connected to each pluggable, interchangeable DCS hardware module via respective interface ports, the field devices configured to perform physical functions to control an industrial process during runtime operation of the industrial process plant; preconfiguring, by each pluggable replaceable DCS hardware module based on the discovery of the one or more physical components, at least a portion of a plant information model of the DCS, wherein the plant information model comprises: a description of a control framework for the industrial process plant, the control framework defining a logical control identifier for each of control components of the DCS and a hierarchical relationship between the control components, the control components including the field devices; and a description of a control network of the industrial process plant utilized to control the industrial process during the runtime operation of the industrial process plant, the control network including the field devices, the respective interface ports, and control routines provided in each of the pluggable interchangeable DCS hardware modules; executing, by each of the pluggable interchangeable DCS hardware modules, the control routine and the respective I / O data delivery mechanism bound to the respective interface port to deliver data between the field device and the control routine, thereby controlling the industrial process.

39. detecting, by each of the pluggable and interchangeable DCS hardware modules, that a particular physical component of the one or more physical components has been newly communicatively connected to the respective pluggable and interchangeable DCS hardware module via at least one of the plurality of interface ports; 39. The method of claim 38, further comprising automatically initiating the discovery of the particular physical component based on the detection of the new communication connection.

40. 40. The method of claim 38 or 39, wherein the plurality of interface ports include at least one of an Advanced Physical Layer port, an analog I / O port, a discrete I / O port, a serial port, a motion port, a near-infrared port, a Railbus port, a Wi-Fi port, an Ethernet port, a HART port, a WirelessHART port, a Fieldbus port, a Profibus port, or another type of interface port.

41. The method of any one of claims 38 to 40, wherein discovering the one or more physical components comprises discovering at least one physical process controller.

42. the DCS further includes an initial set of control functions stored in a set of pluggable, replaceable DCS hardware modules prior to powering up of the DCS; 42. The method of any one of claims 38 to 41, further comprising automatically generating, by each pluggable replaceable DCS hardware module, the control routine corresponding to the field device based on the plant information model and one or more control functions included in the initial set of control functions.

43. 43. The method of claim 42, further comprising packaging the control routine in a container with each pluggable replaceable DCS hardware module, and wherein executing the control routine comprises operating the container.

44. 44. The method of claim 43, further comprising reallocating the container to operate on another pluggable replaceable DCS hardware module based on a change in at least one of load, size, performance metrics, or failure of at least one pluggable replaceable DCS hardware module of the set of pluggable replaceable DCS hardware modules.

45. 45. The method of any one of claims 42 to 44, wherein the initial set of control functions comprises one or more of an adaptive control function, an event-based control function, an advanced control function, a regulatory control function, a batch control function, a sequencing function, an interlock function, a safety shutdown function, a condition detection function, a real-time virtualization controller, or a backup virtualization controller.

46. 46. ​​The method of claim 38, wherein discovering the one or more physical components includes discovering physical I / O devices disposed between the respective interface ports and the field devices, and the field devices communicate process data with the control routines to control the industrial process during the runtime operation via the physical I / O devices.

47. the DCS further includes an initial set of I / O data distribution functions stored in the set of pluggable, replaceable DCS hardware modules prior to initialization of the DCS, the initial set of I / O data distribution functions including one or more of analog I / O functions, discrete I / O functions, motion I / O functions, near-infrared (NIR) I / O functions, another type of I / O transport functions, sampling functions, or signal conditioning functions; The method of any one of claims 38 to 46, wherein the respective I / O data delivery mechanisms corresponding to the field devices are based on the initial set of I / O data delivery functions.

48. 48. The method of claim 47, further comprising automatically generating, by each pluggable replaceable DCS hardware module, at least a portion of the respective I / O data delivery mechanisms corresponding to the plurality of interface ports based on the initial set of I / O data delivery capabilities and the sensed I / O type.

49. packaging the respective I / O data delivery mechanisms corresponding to the field devices with each pluggable replaceable DCS hardware module into a container; 49. The method of claim 48, wherein executing the respective I / O data delivery mechanisms corresponding to the field devices comprises operating the container.

50. the DCS further includes an initial set of support functions stored in the set of pluggable, replaceable DCS hardware modules prior to initialization of the DCS; each support function of the initial set of support functions operates on at least a portion of the data generated by the set of pluggable, interchangeable DCS hardware modules during the runtime operation of the industrial process plant; 50. The method of any one of claims 38 to 49, wherein the initial set of support functions includes at least one of signal processing functions, alarm functions, history functions, trend functions, diagnostic functions, descriptive analytics functions, predictive analytics functions, machine learning functions, reinforcement learning functions, bus functions, or user interface functions.

51. 51. The method of claim 50, further automatically generating, by each pluggable, interchangeable DCS hardware module, additional support functions based on the initial set of support functions and the plant information model.

52. 52. The method of claim 50 or 51, wherein executing the control routine includes receiving, as input to the control routine, at least one of an output of at least one of the initial set of support functions or an output of an additional support function generated based on the initial set of support functions and the plant information model.

53. 53. The method of any one of claims 38 to 52, further comprising exposing a set of application programming interfaces (APIs) to a set of applications, thereby providing the set of applications with access to the plant information model via the set of APIs.

54. 54. The method of claim 53, further comprising storing the set of applications in an application library of the DCS.

55. 55. The method of claim 54, further comprising providing an instance of each of at least some of the set of applications stored in the application library of the DCS to a cloud computing component corresponding to the industrial process plant for access by one or more remote user interfaces associated with the DCS.

56. a first application of the set of applications is provided by a third party; or 56. The method of any one of claims 53-55, wherein a second one or more applications of the set of applications are provided by or are provided by the industrial distributed process control system, and the second one or more applications include at least one of an operator application, a configuration application, an I / O data distribution application, a search application, another type of user interface application, a process control application, a diagnostic application, an operator-facing assistance application, a control system-facing assistance application, a component verification application, a condition monitoring application, a remote monitoring application, a maintenance application, a descriptive analytics application, a predictive analytics application, a machine learning application, or a decision support application.

57. 57. The method of any one of claims 53 to 56, wherein the set of applications includes OT (operational technology) layer applications provided by the industrial distributed process control system, IT (information technology) layer applications provided by an enterprise of the process control system, another type of application provided by the enterprise, a user interface application, a cloud computing application, a decision support application, another type of analytical application, an application running on a mobile device, an application running on another system of the enterprise, or an application provided by and running on a third party system.

58. 58. The method of any one of claims 38 to 57, wherein the plant information model further comprises a description of the one or more physical components of the industrial process plant, a description of respective locations within the industrial process plant at which the one or more physical components are respectively located, and a description of respective interconnections between the one or more physical components.

59. preconfiguring the at least a portion of the plant information model includes preconfiguring the description of the control framework, the description of the control network, and the description of the one or more physical components using a modeling language; the modeling language includes abstractions of data provided to the plant information model by different data sources each utilizing a different data format; 59. The method of claim 58, further comprising exposing a set of application programming interfaces (APIs) to provide a set of applications of the DCS access to the information stored in the plant information model by utilizing the modeling language.

60. 60. The method of any one of claims 38-59, wherein each pluggable, interchangeable DCS hardware module further includes a set of security applications stored in each pluggable, interchangeable DCS hardware module prior to powering up of each pluggable, interchangeable DCS hardware module, the one or more security applications protecting at least one of the contents of the plant information model or access to the contents of the plant information model.

61. 61. The method of any one of claims 38-60, wherein the set of pluggable, interchangeable DCS hardware modules is a plurality of pluggable, interchangeable DCS hardware modules, the method further comprising, upon establishment of a communication connection between each pluggable, interchangeable DCS hardware module and another pluggable, interchangeable DCS hardware module, discovering the other pluggable, interchangeable DCS hardware module by the each pluggable, interchangeable DCS hardware module.

62. 62. The method of claim 61, further comprising distributing, among the plurality of pluggable DCS hardware modules, at least one of: (i) the plant information model; (ii) a set of application programming interfaces (APIs) exposed to a set of applications and providing the set of applications with access to the plant information model; (iii) the respective I / O data delivery mechanisms; or (iv) a set of control routines, the set of control routines including the control routines corresponding to the field devices.

63. 63. The method of claim 62, further comprising automatically reallocating the distribution of at least one of (i), (ii), (iii), or (iv) among the plurality of pluggable, replaceable DCS hardware modules in response to a change to at least one of load, size, performance metric, or failure corresponding to at least one pluggable, replaceable DCS hardware module of the plurality of pluggable, replaceable DCS hardware modules.

Images