Patent Description:
Industrial process control and automation systems are often used to automate large and complex industrial processes. These types of control and automation systems routinely include process controllers and field devices like sensors and actuators. Some of the process controllers typically receive measurements from the sensors and generate control signals for the actuators.

Model-based industrial process controllers are one type of process controller routinely used to control the operations of industrial processes. Model-based process controllers typically use one or more models to mathematically represent how one or more properties within an industrial process respond to changes made to the industrial process. Unfortunately, the benefits that can be obtained using model-based controllers often decline over time. This can be due to a number of factors, such as inaccurate models, misconfiguration, or operator actions. In some extreme cases, the benefits that could be obtained using model-based controllers can be reduced by up to fifty percent or even more over time. <CIT> relates to a method and apparatus for intelligent control and monitoring in a process control system. The controller includes a control module to control operation of a process in response to control data, a plug-in module coupled to the control module as a non-layered, integrated extension thereof, and a model identification engine. <CIT> relates to process control system integrating the collection and analysis of process control data used to perform certain computationally expensive process control functions, like adaptive model generation and tuning parameter generation, in the same control device in which one or more of the process control routines are implemented, to thereby provide for faster and more efficient support of the process control routines. <CIT> relates to a system and method for controlling a process such as an oil production process is disclosed. The system comprises multiple intelligent agents for processing data received from a plurality sensors deployed in a job site of an oil well, and applies a probabilistic model for evaluating risk and recommending appropriate control action to the process. <CIT> relates to an apparatus and a method for high performance data analysis. The system comprises a society of processing modules that collectively interact with one another until steady state equilibrium is reached, in order to solve a given problem.

The present invention relates to a method, an apparatus and a non-transitory computer readable medium according to the appended claims. This disclosure provides an apparatus and method for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers.

A first embodiment is a method according to claim <NUM>.

A second embodiment is an apparatus according to claim <NUM>.

A third embodiment is a non-transitory computer readable medium according to claim <NUM>.

<FIG>, discussed below, and the various examples used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the invention may be implemented in any type of suitably arranged device or system.

As noted above, model-based industrial process controllers are one type of process controller routinely used to control the operations of industrial processes. Model-based process controllers can help to improve the performance of continuous or other industrial processes. For example, in industrial processes, a controlled variable (CV) generally represents a process variable that can be measured or inferred and that is ideally controlled to be at or near a desired setpoint or within a desired range of values. A manipulated variable (MV) generally represents a process variable that can be adjusted in order to alter one or more controlled variables. A disturbance variable (DV) generally represents a process variable whose value can be considered but cannot be controlled. As a simple example, a flow rate of material through a pipe could denote a controlled variable, a valve opening for a valve that controls the flow rate of material could denote a manipulated variable, and an ambient temperature around the pipe or the valve could denote a disturbance variable.

Model-based control techniques are used in various process industries, such as to drive complex systems that are interactive with transport delays to operate at their limits while delivering operational performance and economic benefits to their owners or operators. Unfortunately, as noted above, the benefits of model-based controllers often decline over time due to various factors. One reason for this decline is that operations leaders (decision makers) responsible for managing performance may not understand the business or other impacts caused by instrumentation issues, operator behaviors, soft sensor performance, and model mismatch that can limit model-based controllers' performance. It can also be difficult to quantify the loss of model-based controller benefits, pinpoint root causes for the losses, and resolve the losses based on the identified causes. Further, organizations often have different model-based controller vendors and controller versions installed across their sites, and there is currently no way to provide a seamless mechanism that quantifies a loss of benefits that is vendor- and version-neutral. In addition, organizations often have engineering teams that monitor process performance, and these teams often need specific contextual visualizations for controller issue resolutions based on their scopes of responsibility and user roles.

This disclosure provides a framework that can be used to identify model-based controller issues, visualize the controller issues and their impacts along with auto-suggested actions, and trigger workflows and/or actions to resolve the controller issues across a plant or enterprise. In some examples, the impacts are expressed in terms of economic impacts, such as monetary losses. Of course, the impacts could be expressed in other ways, such as excess material usage, excess energy usage, or reduced product production. A "cost" of an impact can serve as a measure of the excess material usage, excess energy usage, reduced product production, economic loss, or other impact. Among other things, the framework can be used to increase the effectiveness of model-based controllers in driving units or other equipment to optimal operating targets, thereby reclaiming lost benefits.

The framework described in more detail below can be scalable and elastic, such as through the use of analytic containers that can be instantiated and executed as needed to process data and identify issues affecting model-based controllers. In some examples, a single instance of the framework could be deployed and used to analyze data associated with multiple model-based controllers, which can be located at a single industrial site or at multiple industrial sites. Multiple instances of the framework could also be deployed in and used with one or more industrial sites. Also or alternatively, one or more instances of the framework could be deployed "in the cloud" or at locations remote from one or more industrial sites.

In this way, the framework helps to identify different operational issues that can affect a model-based controller, the impacts of those operational issues, and possible remedies for those operational issues. The results of the analyses can then be used to modify the operation of the model-based controller or other components in order to reduce the impacts of the operational issues, which affects how the controller controls the underlying industrial process.

Among other things, this could enable a new Industrial Internet of Things (IIoT) service or other service to be deployed, where the service can be used to reduce the cost of troubleshooting a model-based controller's performance and to improve the lifecycle benefits of the model-based controller. In particular examples, these techniques could be implemented using a computer program that periodically analyses batches of data collected from customers' premises as part of a cloud-based analytics solution. The resulting analysis conclusions could then be visualized to the customers using cloud-hosted dashboards to enable the customers, support engineering teams, or other personnel to view performance information and troubleshoot performance issues.

<FIG> illustrates an example industrial process control and automation system <NUM> according to this disclosure. As shown in <FIG>, the system <NUM> includes various components that facilitate production or processing of at least one product or other material. For instance, the system <NUM> can be used to facilitate control over components in one or multiple industrial plants. Each plant represents one or more processing facilities (or one or more portions thereof), such as one or more manufacturing facilities for producing at least one product or other material. In general, each plant may implement one or more industrial processes and can individually or collectively be referred to as a process system. A process system generally represents any system or portion thereof configured to process one or more products or other materials in some manner.

In <FIG>, the system <NUM> includes one or more sensors 102a and one or more actuators 102b. The sensors 102a and actuators 102b represent components in a process system that may perform any of a wide variety of functions. For example, the sensors 102a could measure a wide variety of characteristics in the process system, such as flow, pressure, or temperature. Also, the actuators 102b could alter a wide variety of characteristics in the process system, such as valve openings. Each of the sensors 102a includes any suitable structure for measuring one or more characteristics in a process system. Each of the actuators 102b includes any suitable structure for operating on or affecting one or more conditions in a process system.

At least one network <NUM> is coupled to the sensors 102a and actuators 102b. The network <NUM> facilitates interaction with the sensors 102a and actuators 102b. For example, the network <NUM> could transport measurement data from the sensors 102a and provide control signals to the actuators 102b. The network <NUM> could represent any suitable network or combination of networks. As particular examples, the network <NUM> could represent at least one Ethernet network (such as one supporting a FOUNDATION FIELDBUS protocol), electrical signal network (such as a HART network), pneumatic control signal network, or any other or additional type(s) of network(s).

The system <NUM> also includes various controllers <NUM>. The controllers <NUM> can be used in the system <NUM> to perform various functions in order to control one or more industrial processes. For example, a first set of controllers <NUM> may use measurements from one or more sensors 102a to control the operation of one or more actuators 102b. A second set of controllers <NUM> could be used to optimize the control logic or other operations performed by the first set of controllers. A third set of controllers <NUM> could be used to perform additional functions. The controllers <NUM> could therefore support a combination of approaches, such as regulatory control, advanced regulatory control, supervisory control, and advanced process control.

Each controller <NUM> includes any suitable structure for controlling one or more aspects of an industrial process. At least some of the controllers <NUM> could, for example, represent proportional-integral-derivative (PID) controllers or multivariable controllers, such as controllers implementing model predictive control (MPC) or other advanced predictive control (APC). As a particular example, each controller <NUM> could represent a computing device running a real-time operating system, a WINDOWS operating system, or other operating system.

At least one of the controllers <NUM> shown in <FIG> denotes a model-based controller that operates using one or more process models. For example, each of these controllers <NUM> could operate using one or more process models to determine, based on measurements from one or more sensors 102a, how to adjust one or more actuators 102b. In some examples, each model associates one or more manipulated or disturbance variables (often referred to as independent variables) with one or more controlled variables (often referred to as dependent variables). Each of these controllers <NUM> could use an objective function to identify how to adjust its manipulated variables in order to push its controlled variables to the most attractive set of constraints.

At least one network <NUM> couples the controllers <NUM> and other devices in the system <NUM>. The network <NUM> facilitates the transport of information between components. The network <NUM> could represent any suitable network or combination of networks. As particular examples, the network <NUM> could represent at least one Ethernet network.

Operator access to and interaction with the controllers <NUM> and other components of the system <NUM> can occur via various operator consoles <NUM>. Each operator console <NUM> could be used to provide information to an operator and receive information from an operator. For example, each operator console <NUM> could provide information identifying a current state of an industrial process to the operator, such as values of various process variables and warnings, alarms, or other states associated with the industrial process. Each operator console <NUM> could also receive information affecting how the industrial process is controlled, such as by receiving setpoints or control modes for process variables controlled by the controllers <NUM> or other information that alters or affects how the controllers <NUM> control the industrial process. Each operator console <NUM> includes any suitable structure for displaying information to and interacting with an operator. For example, each operator console <NUM> could represent a computing device running a WINDOWS operating system or other operating system.

Multiple operator consoles <NUM> can be grouped together and used in one or more control rooms <NUM>. Each control room <NUM> could include any number of operator consoles <NUM> in any suitable arrangement. In some examples, multiple control rooms <NUM> can be used to control an industrial plant, such as when each control room <NUM> contains operator consoles <NUM> used to manage a discrete part of the industrial plant.

The control and automation system <NUM> here may optionally include at least one historian <NUM> and/or one or more servers <NUM>. The historian <NUM> represents a component that stores various information about the system <NUM>. The historian <NUM> could, for instance, store information that is generated by the various controllers <NUM> during the control of one or more industrial processes. The historian <NUM> includes any suitable structure for storing and facilitating retrieval of information. Although shown as a single component here, the historian <NUM> could be located elsewhere in the system <NUM>, or multiple historians could be distributed in different locations in the system <NUM>.

Each server <NUM> denotes a computing device that executes applications for users of the operator consoles <NUM> or other applications. The applications could be used to support various functions for the operator consoles <NUM>, the controllers <NUM>, or other components of the system <NUM>. Each server <NUM> could represent a computing device running a WINDOWS operating system or other operating system. Note that while shown as being local within the control and automation system <NUM>, the functionality of the server <NUM> could be remote from the control and automation system <NUM>. For instance, the functionality of the server <NUM> could be implemented in a computing cloud <NUM> or a remote server communicatively coupled to the control and automation system <NUM> via a gateway <NUM>.

At least one component of the system <NUM> could support a mechanism for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers. For example, this functionality could be implemented in an operator console <NUM>, a server <NUM>, or a computing cloud <NUM> or remote server. Among other things, this functionality can be used to evaluate data associated with one or more model-based controllers <NUM> to identify operational issues affecting the controller(s) <NUM>, and the impacts of any identified operational issues and possible remedies for the identified operational issues can be determined. Visualizations can also be provided, such as on displays of the operator consoles <NUM>, to help users identify the operational issues, their impacts, and possible resolutions. Ideally, this allows the operational issues to be prioritized and reduced or resolved, which can help to improve the operation of the model-based controllers <NUM>. Additional details regarding this functionality are provided below.

Although <FIG> illustrates one example of an industrial process control and automation system <NUM>, various changes may be made to <FIG>. For example, the system <NUM> could include any number of sensors, actuators, controllers, networks, operator consoles, control rooms, historians, servers, and other components. Also, the makeup and arrangement of the system <NUM> in <FIG> is for illustration only. Components could be added, omitted, combined, further subdivided, or placed in any other suitable configuration according to particular needs. As a particular example, the historian <NUM> may be implemented in the computing cloud <NUM>. Further, particular functions have been described as being performed by particular components of the system <NUM>. This is for illustration only. In general, control and automation systems are highly configurable and can be configured in any suitable manner according to particular needs. In addition, <FIG> illustrates one example operational environment where identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers can be used. This functionality can be used in any other suitable system.

<FIG> illustrates an example device <NUM> for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers according to this disclosure. The device <NUM> could, for example, denote an operator console <NUM>, server <NUM>, or device used in the computing cloud <NUM> described above with respect to <FIG>. However, the device <NUM> could be used in any other suitable system.

As shown in <FIG>, the device <NUM> includes at least one processor <NUM>, at least one storage device <NUM>, at least one communications unit <NUM>, and at least one input/output (I/O) unit <NUM>. Each processor <NUM> can execute instructions, such as those that may be loaded into a memory <NUM>. The instructions could identify, visualize, and trigger workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers. Each processor <NUM> denotes any suitable processing device, such as one or more microprocessors, microcontrollers, digital signal processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or discrete circuitry.

The memory <NUM> and a persistent storage <NUM> are examples of storage devices <NUM>, which represent any structure(s) capable of storing and facilitating retrieval of information (such as data, program code, and/or other suitable information on a temporary or permanent basis). The memory <NUM> may represent a random access memory or any other suitable volatile or non-volatile storage device(s). The persistent storage <NUM> may contain one or more components or devices supporting longer-term storage of data, such as a read only memory, hard drive, Flash memory, or optical disc.

The communications unit <NUM> supports communications with other systems or devices. For example, the communications unit <NUM> could include a network interface card or a wireless transceiver facilitating communications over a wired or wireless network. The communications unit <NUM> may support communications through any suitable physical or wireless communication link(s).

The I/O unit <NUM> allows for input and output of data. For example, the I/O unit <NUM> may provide a connection for user input through a keyboard, mouse, keypad, touchscreen, or other suitable input device. The I/O unit <NUM> may also send output to a display, printer, or other suitable output device.

Although <FIG> illustrates one example of a device <NUM> for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers, various changes may be made to <FIG>. For example, components could be added, omitted, combined, further subdivided, or placed in any other suitable configuration according to particular needs. Also, computing devices can come in a wide variety of configurations, and <FIG> does not limit this disclosure to any particular configuration of computing device.

<FIG> illustrates an example framework <NUM> for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers according to this disclosure. For ease of explanation, most of the framework <NUM> is described as being provided by the device <NUM> of <FIG> implementing an operator console <NUM>, server <NUM>, or device used in the computing cloud <NUM> of <FIG>. However, the framework <NUM> could be used with any suitable device(s) and in any suitable system.

As shown in <FIG>, the framework <NUM> is implemented using a client-server architecture that includes at least one client node <NUM> and at least one server node <NUM>. Each client node <NUM> generally represents a computing device or other device used by a user to interact with a server node <NUM>. Each server node <NUM> generally represents a computing device that executes applications or other logic for providing desired functionality. Each client node <NUM> includes any suitable device for interacting with a server or other computer, such as a desktop computer, laptop computer, tablet computer, or smartphone. Each server node <NUM> includes any suitable computing device for executing applications or other logic and could have the same general structure shown in <FIG>.

In this example, each client node <NUM> includes or executes a web browser <NUM>, which denotes an application or other logic that allows a user to interact with other devices (including the server node <NUM>) using the Hypertext Transfer Protocol (HTTP) or other network-based protocol. Also, in this example, the server node <NUM> includes or executes a web server <NUM>, which interacts with the web browser <NUM> in order to support communications between the nodes <NUM> and <NUM>. The web server <NUM> generally represents an application or other logic that processes incoming HTTP or other requests from external devices and that serves data to external devices. Among other things, as described in more detail below, the web server <NUM> can receive data associated with operation of one or more model-based controllers <NUM> and provide the data for storage or analysis. The web server <NUM> can also provide requests for analysis of that data to other components of the server node <NUM> and provide results based on the analysis to at least one client node <NUM>, such as in the form of one or more graphical displays.

The server node <NUM> also includes or has access to an asset model <NUM> and a configuration database <NUM>. The asset model <NUM> stores information defining assets and their relationships with other assets (such as in a parent-child format or other multi-level format). An asset represents any hardware, software, or other physical or virtual component within a process control and automation system or an underlying industrial process being controlled. The assets identified in the asset model <NUM> could be associated with a single industrial site (or a portion thereof), multiple industrial sites (or portions thereof), or an entire enterprise. The assets identified in the asset model <NUM> include one or more model-based controllers <NUM>. For each model-based controller <NUM>, the asset model <NUM> can define the controller <NUM> as an asset and associate it as a child of a process unit asset or other equipment for which the controller <NUM> is built. Metadata for each controller <NUM>, such as its vendor, version, and application type, can be stored in the asset model <NUM> for that controller <NUM>. Metadata for each controller <NUM> could also include the inputs and outputs for that controller <NUM> and can be stored in the asset model <NUM>.

The asset model <NUM> can also store information defining different scopes of responsibility and how those scopes are mapped to different assets or different levels of assets within the asset model <NUM>. Different user roles can be assigned to the scopes of responsibility, and specific users can be assigned to specific user roles. In this way, the asset model <NUM> can be used to define specific scopes of responsibility for users and the assets associated with those users. This allows consistent scopes of responsibility to be achieved across a plant or enterprise.

The configuration database <NUM> stores information defining how data associated with one or more model-based controllers <NUM> will be analyzed. For example, the configuration database <NUM> could identify the frequency at which analytics algorithms should be executed for one or more model-based controllers <NUM>. As a particular example, the configuration database <NUM> could store an execution plan for an individual model-based controller <NUM>, a group of model-based controllers <NUM>, or all model-based controllers <NUM>. Any number of execution plans could be supported in the configuration database <NUM>. Each execution plan and its associated controller asset and controller metadata could be published to other components of the server node <NUM> to support analysis of controller data for the associated controller <NUM>.

The server node <NUM> further includes or has access to various analysis algorithm images <NUM>. The analysis algorithm images <NUM> represent data analysis routines that could be used to analyze data from a model-based controller <NUM> in order to identify possible operational issues with the controller <NUM>. The analysis algorithm images <NUM> could be defined in any suitable manner, such as by a provider of an analysis software package executed by the server node <NUM> or by engineers or other personnel associated with a process control and automation system. Each analysis algorithm image <NUM> could support any suitable computations or other operations used to process data associated with a model-based controller <NUM> and determine whether (and to what extent) the controller <NUM> is suffering from an operational problem.

A batch execution engine <NUM> instantiates various ones of the analysis algorithm images <NUM> into analysis containers <NUM> and then executes the analysis containers <NUM>. For example, based on an execution plan contained in or published from the configuration database <NUM>, the batch execution engine <NUM> can select one or more suitable analysis algorithm images <NUM> for a controller <NUM> (such as based on the controller's vendor, version, and application type) and instantiate one or more containers <NUM> for the selected image(s) <NUM>. The batch execution engine <NUM> can then execute analytics routines contained in the containers <NUM> and output the results, such as to a historian <NUM> or other database for storage. In this way, the batch execution engine <NUM> uses the analysis algorithm images <NUM> and the analysis containers <NUM> to execute logic that analyzes controller-related data in order to identify any operational issues that might be affecting the controller <NUM> and the impacts of those operational issues. In some examples, the batch execution engine <NUM> can represent a set of services or other logic that instantiates and monitors jobs, providing elasticity and scalability by adding or removing jobs based on demand and availability of computing resources.

Each container <NUM> can package all algorithm dependencies for a particular analysis algorithm within itself. This allows each container <NUM> to be instantiated and executed in any suitable system, thereby enabling the framework <NUM> to be scalable and elastic. Based on a particular controller's vendor and version and the specific controller issue to be identified, an associated analytics algorithm can be instantiated from its image <NUM> and executed independently using a container <NUM>. For automatic identification of specific controller issues, the framework <NUM> can provide generic container interface functions to input data to containers <NUM>, execute analytics in the containers <NUM>, and output results from the containers <NUM> (such as in a standard format) for each specific controller issue based on its schema. This helps to keep the framework <NUM> version- and vendor- neutral.

In addition, the server node <NUM> includes a workflow engine <NUM> and a security module <NUM>. The workflow engine <NUM> generally operates to identify workflows or other actions that could be used to reduce or resolve the impacts of operational issues affecting the model-based controllers <NUM>. The workflow engine <NUM> can also be used to trigger initiation or execution of selected workflows or other actions, such as based on user input once a user has viewed the analysis results generated by the batch execution engine <NUM>. The results of the execution of the workflows or other actions (such as their disposition statuses) could be stored and maintained to support traceability and auditing.

The security module <NUM> can be used to support a secure data transfer mechanism between the server node <NUM> and other components (such as the controllers <NUM>, historian <NUM>, or client nodes <NUM>). The secure data transfer mechanism helps to protect the data being collected by the server node <NUM>, such as when the data is collected from remote sources over the Internet or other unsecure network. Any suitable secure data transfer technique could be supported by the security module <NUM>. Note, however, that if the server node <NUM> resides within a control and automation system <NUM>, there may be little or no need to use a secure data transfer mechanism to protect data being transferred to the server node <NUM>.

The web server <NUM> in the framework <NUM> can be used to provide graphical user interfaces to users of the client nodes <NUM>. The graphical user interfaces can be provided so that different users are able to understand and use the results of the analyses performed by the server node <NUM>. For example, the graphical user interfaces can help users to identify how units or other equipment at an industrial site are being driven by various process models used by their controllers <NUM> and the associated economic or other costs. The graphical user interfaces can also help users to identify which instruments or models need maintenance and which equipment needs cleaning or regeneration. The graphical user interfaces can further help users to identify which operators need training or which process variable targets are unachievable or overly conservative. The framework <NUM> can also provide contextual visualizations and prioritized recommendations to the users in the graphical user interfaces, such as based on their scopes of responsibility and user roles, in order to improve the implementation of optimal conditions.

In some examples, analysis results can be presented in different graphical user interfaces based on the roles of the users using the graphical user interfaces. For example, an operations management view in a graphical user interface could allow an operations manager to understand the impacts of operator behaviors, equipment issues, and other external factors on a model-based controller <NUM> and consequently the impacts of those factors on performance of the industrial process and the health of equipment in the industrial process. Specific visualizations (such as tree maps) can show weighted economic or other benefits or costs and drilldown in the asset hierarchy defined by the asset model <NUM>. A process engineer's view in a graphical user interface could highlight the impacts of key constraint limits on the performance of the industrial process. A control engineer's view in a graphical user interface could provide detailed diagnostic insights into underlying causes of good or poor controller performance, possibly along with an assessment of the economic or other impacts of the underlying issues to help justify corrective actions (such as process or application maintenance or operator training). Specific controller issues related to particular entities in the asset model <NUM> can be listed priority-wise, along with their economic or other impacts, to focus on actions that realize the most benefits. Rolled-up economic or other benefits per shift can be shown to check if any operator needs mentoring on controller aspects.

The framework <NUM> shown in <FIG> is therefore able to perform various functions in a cohesive process to provide intuitive progression from surfacing a controller issue to its resolution. These functions include automatic identification of controller issues, contextual visualization of the controller issues, and resolution of the controller issues. The automatic identification of controller issues is supported by the batch execution engine <NUM>, which instantiates the analysis algorithm image(s) <NUM> appropriate for a specific controller <NUM> into one or more containers <NUM> for execution. Controller issues discovered using the executed analytics can be prioritized, such as based on weighted economic or other benefits or impacts. In some cases, the controller issues can be ranked with the issues having the maximum impacts listed first. In some examples, economic or other benefits or impacts estimated using the executed analytics can be aggregated and rolled-up to higher-level entities in the asset model <NUM> (such as to those levels that make sense to operations leaders, unit managers, and process engineers). The amount of roll-up and aggregation can be based on different user roles.

The contextual visualization of controller issues is supported by the generation of different graphical user interfaces for presentation to different users (such as operations leaders, unit managers, and process engineers). The visualizations can include graphical representations of controller issues and related auto-suggested actions that are based on selected entities in the asset model <NUM>, the users' roles, and the users' scopes of responsibility. One example goal for the use of the contextual visualizations could be to provide a good line of sight between the issues that impact a model-based controller's performance and how to resolve those issues. Another example goal could be to reduce the difficulty and cost of maintaining and improving the performance of the industrial process and the model-based controller(s) <NUM> in the control and automation system. In specific examples, this approach can help to improve collaboration between the operations management, process engineering, and control engineering personnel in order to maintain and improve the performance of the industrial process while leveraging the model-based controller(s) <NUM> to achieve the best effect. Note, however, that the approaches described in this patent document could be used in any other suitable manner.

The resolution of controller issues is supported by providing prioritized recommendations based on weighted benefits or impacts to the users so that the users can take or initiate actions, possibly through the graphical user interfaces. Example recommendations for controller issues could include changes to process variable limits and/or controller tuning parameters, mentoring operators on controller behaviors, model changes, re-calibration of soft sensors, and repairing malfunctioning instrumentation. The graphical user interfaces can provide users with the ability to trigger workflows or initiate auto-suggested actions. As an example, suppose a controller issue has an auto-suggestion to change a particular model. The framework <NUM> can offer an option to a user for initiating a stepper application or other application to identify a new model for the controller <NUM>. If the recommendation is to repair malfunctioning instrumentation, the framework <NUM> can offer an option to a user for initiating a work order to repair the equipment. Comments and action disposition statuses can be recorded to maintain traceability and to audit the resolution of controller issues.

Note that the framework <NUM> shown in <FIG> is implemented using a client-server architecture, which itself could be implemented in various ways. For example, one or more client nodes <NUM> and one or more server nodes <NUM> could be implemented "on premises," meaning completely within a single industrial site or within an enterprise's overall system. Alternatively, one or more client nodes <NUM> could reside within a process control and automation system <NUM>, while one or more server nodes <NUM> reside "in the cloud" or at some remote location(s) and provide the described functionality as a service. Of course, other architectures could also be used, such as when the functionality of the server node <NUM> is installed completely on each user's computing device. There could also be a single instance or multiple instances of the framework <NUM> used for a single industrial site or multiple industrial sites, and each instance of the framework <NUM> could be used by a single enterprise or multiple enterprises.

Also note that each component of the server node <NUM> in <FIG> could be implemented in any suitable manner. For example, the asset model <NUM>, configuration database <NUM>, analysis algorithm images <NUM>, and analysis containers <NUM> could be stored in the storage device(s) <NUM> of the device <NUM> using any suitable data structures. Also, each of the web server <NUM>, batch execution engine <NUM>, workflow engine <NUM>, and security module <NUM> could be implemented using software/firmware instructions that are executed by the processor(<NUM>) of the device <NUM>. In addition, the historian <NUM> could represent any suitable information storage and retrieval device within or outside of the device <NUM>, such as the storage device(s) <NUM> or an external database (like the historian <NUM>).

Although <FIG> illustrates one example of a framework <NUM> for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers, various changes may be made to <FIG>. For example, the functional divisions shown in <FIG> are for illustration only. Various data elements could be combined, further subdivided, or omitted and additional data elements could be added according to particular needs. Also, various functional elements could be combined, further subdivided, or omitted and additional functional elements could be added according to particular needs.

<FIG> and <FIG> illustrate an example graphical user interface <NUM> for visualizing and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers according to this disclosure. The graphical user interface <NUM> could, for example, be generated by the server node <NUM> and be presented to at least one user who is using at least one client device <NUM>. For ease of explanation, the graphical user interface <NUM> is described as being generated by the device <NUM> of <FIG> implementing an operator console <NUM>, server <NUM>, or device used in the computing cloud <NUM> of <FIG>. However, the graphical user interface <NUM> could be generated by any suitable device and in any suitable system.

As shown in <FIG> and <FIG>, the graphical user interface <NUM> includes various information about specific equipment that implements at least part of an industrial process. This specific equipment could be selected in any suitable manner, such as by using a tree identifying a hierarchy of equipment that can be navigated by a user or by using another display that identifies or includes at least the specific equipment.

For the specific selected equipment, the graphical user interface <NUM> includes a section <NUM> identifying the long-term performance of the equipment and a section <NUM> identifying how the equipment operates during different work shifts (which are associated with different human operators). The graphical user interface <NUM> also includes a section <NUM> identifying the behaviors of key process variables associated with the selected equipment and a section <NUM> identifying limit violations (if any) for the selected equipment. This information could be generated in any suitable manner, such as when the limit violations are identified using the techniques disclosed in U. Patent Application No. <CIT> entitled "APPARATUS AND METHOD FOR AUTOMATED IDENTIFICATION AND DIAGNOSIS OF CONSTRAINT VIOLATIONS" (filed concurrently herewith).

The graphical user interface <NUM> further includes a section <NUM> that identifies how operational issues affect the performance of at least one model-based controller associated with the selected equipment. In this example, the section <NUM> identifies different contributory causes (operational issues) that result in reduced controller performance and how each of those causes contributes to lost opportunity costs (expressed in terms of a lost opportunity cost). The lost opportunity costs identify improvements that could be made to the operation of a model-based controller <NUM>.

A section <NUM> identifies one or more possible corrective courses of action that could be taken to reduce or resolve one or more of the operational issues identified in section <NUM>. The possible corrective courses of action could be identified in any suitable manner, such as based on information in a knowledge repository or based on operation of the workflow engine <NUM>. In some examples, the section <NUM> also allows each corrective course of action to be triggered by a user. For instance, the possible corrective courses of action identified in section <NUM> could be displayed as hyperlinks, which can be selected by the user in order to initiate a workflow or other action used to implement the selected course of action. Buttons <NUM> could also be displayed for the corrective courses of action and can be used by the user to enter notes, trigger or close the courses of action, or perform other functions. Tabs <NUM> allow the user to view open courses of action, courses of action that are currently being performed, and shelved or closed courses of action.

Although <FIG> and <FIG> illustrate one example of a graphical user interface <NUM> for visualizing and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers, various changes may be made to <FIG> and <FIG>. For example, the content and layout of the graphical user interface <NUM> could vary as needed or desired. As a particular example, the graphical user interface <NUM> could vary based on the user role of the user who is to view the graphical user interface <NUM>.

<FIG> illustrates an example method <NUM> for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers according to this disclosure. For ease of explanation, the method <NUM> is described as being performed by the device <NUM> of <FIG> implementing an operator console <NUM>, server <NUM>, or device used in the computing cloud <NUM> of <FIG>. However, the method <NUM> could be used with any suitable device and in any suitable system.

As shown in <FIG>, a start and an end of an analysis period are identified at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> determining the period during which data associated with a model-based controller <NUM> will be analyzed. Any suitable period of time could be identified here, such as a particular day, week, month, or other period of time. In some examples, the analysis period for a controller <NUM> can be defined based on the published execution plan contained in the configuration database <NUM> for that controller <NUM>.

Data associated with the model-based controller is obtained at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> obtaining data identifying values of process variables used by the controller <NUM> and other data associated with the controller <NUM>. This could also include the processor <NUM> of the device <NUM> pre-processing the data, such as to validate the obtained data and discard any portions of the obtained data deemed invalid. Note that when the data is obtained by a device that is remote from the controller <NUM> or other data source, the data can be transmitted to the device securely and in real-time, near real-time, or non-real-time depending on the example.

The data is analyzed to identify at least one impact associated with one or more operational problems affecting the controller at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to analyze the data and determine whether the controller <NUM> is suffering from issues that prevent the controller <NUM> from achieving its maximum potential benefits. As noted above, the impacts could be expressed in any suitable terms, such as excess material usage, excess energy usage, reduced product production, or economic costs (and economic costs could themselves be a measure of things like excess material usage, excess energy usage, or reduced product production).

One or more recommended actions for reducing or eliminating at least one of the impacts are identified at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> executing the workflow engine <NUM> to identify possible corrective actions that could be used to reduce the impacts of the identified operational issues. Any suitable recommended actions could be identified here, and the recommended action(s) identified for a particular impact can be based on the specific operational issue causing the impact. For example, changes to process variable limits and/or controller tuning parameters could be recommended when an operational issue relates to over-constrained process variables or improperly configured controllers. Mentoring operators on controller behaviors could be recommended when an operational issue relates to process variables being placed into improper modes or being dropped from consideration by a controller <NUM>. Model changes could be recommended when an operational issue relates to the quality of one or more models used by a controller <NUM>. Re-calibration of soft sensors could be recommended when an operational issue relates to the quality of one or more inferred properties used by a controller <NUM>. Repairing malfunctioning instrumentation could be recommended when an operational issue relates to invalid data being received.

A graphical display identifying at least one of the impacts and at least one of the recommended actions is generated and presented to one or more users at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> generating a graphical user interface that identifies one or more of the impacts and one or more of the recommended actions in a control-relevant context. The impacts could be ranked, such as in order of decreasing costs or other impacts or in order of increasing benefits that could be obtained. The recommended actions could also be ranked, such as based on the associated impacts. In some examples, the analysis results may be intended for different types of personnel, such as process managers, engineers, or other personnel. As a result, the analysis results in a graphical display could be expressed in appropriate terms for each type of user, such as based on each user's user role or scope of responsibility. The analysis results could also be presented based on a specific asset or assets selected in the asset model <NUM> for which the data is being analyzed.

One or more recommended actions are triggered based on user input at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> receiving user input indicating that at least one of the recommended actions presented in the graphical display should be initiated or otherwise performed. This could also include the workflow engine <NUM> initiating the recommended action(s) and tracking the status of each triggered action. An action could be performed in any suitable manner, such as by the device <NUM> or by personnel who respond to workflow requests or requests issued by the device <NUM> or another system.

Although <FIG> illustrates one example of a method <NUM> for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers, various changes may be made to <FIG>. For example, while shown as a series of steps, various steps in <FIG> could overlap, occur in parallel, occur in a different order, or occur any number of times.

<FIG> illustrates an example method <NUM> for analyzing data to identify suggested actions to reclaim lost benefits of model-based industrial process controllers according to this disclosure. The method <NUM> could, for example, be performed during step <NUM> in the method of <FIG>. For ease of explanation, the method <NUM> is described as being performed by the device <NUM> of <FIG> implementing an operator console <NUM>, server <NUM>, or device used in the computing cloud <NUM> of <FIG>. However, the method <NUM> could be used with any suitable device and in any suitable system.

As shown in <FIG>, one or more analytic algorithms are selected for analyzing data associated with a model-based controller at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to identify metadata associated with a controller <NUM>, such as its vendor, version, and operational problem to be detected. This could also include the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to select one or more analysis algorithm images <NUM> based on the metadata. The one or more selected analytic algorithms are instantiated into one or more containers at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to generate an executable container <NUM> for each selected analysis algorithm image <NUM>.

The one or more containers are executed to analyze the data associated with the controller at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to analyze the data associated with the controller <NUM> using the logic contained in the one or more containers <NUM>. The logic in the container(s) <NUM> is used to analyze the data and identify possible operational issues affecting the controller <NUM>. The logic in the container(s) is also used to estimate the impact or impacts associated with each of the identified operational issues.

The results of the execution are transformed into a standard format at step <NUM>. This could include, for example, the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to translate any identified operational issues into a standard form, such as a description of the operational issue and any likely causes of the operational issue. This could also include the processor <NUM> of the device <NUM> executing the batch execution engine <NUM> to translate any identified impacts into a standard form, such as a description of the impact and an associated measure of the impact (like in terms of a cost or lost benefit). Note that the standard format used here does not require the use of a format that is approved by a standards body. Rather, the standard format can denote any suitable format that is standardized across different operational issues and impacts, even if the standard format is proprietary.

Although <FIG> illustrates one example of a method <NUM> for analyzing data to identify suggested actions to reclaim lost benefits of model-based industrial process controllers, various changes may be made to <FIG>. For example, while shown as a series of steps, various steps in <FIG> could overlap, occur in parallel, occur in a different order, or occur any number of times. Also, the use of containers is optional, and analytic algorithms can be executed in any other suitable manner. In addition, the transformation of analysis results may not be required, such as when the analytic algorithms are themselves configured to generate analysis results in a desired format.

In some examples, various functions described in this patent document are implemented or supported by a computer program that is formed from computer readable program code and that is embodied in a computer readable medium. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable storage device.

It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer code (including source code, object code, or executable code). The term "communicate," as well as derivatives thereof, encompasses both direct and indirect communication. The phrase "associated with," as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like.

Claim 1:
A method comprising:
obtaining (<NUM>) data associated with operation of a model-based industrial process controller (<NUM>);
identifying (<NUM>) impacts of operational problems of the model-based industrial process controller;
generating (<NUM>) a graphical display (<NUM>) for a user, the graphical display presents one or more recommended actions to eliminate at least one of the impacts of at least one of the operational problems; and
triggering (<NUM>) at least one of the one or more recommended actions based on input from the user,
the graphical display being generated based on at least one of: a user role for the user, a scope of responsibility for the user, and an asset selected in an asset model,
the method being characterized in that
the graphical display presents one or more operational issues associated with the model-based industrial process controller, wherein the one or more operational issues are prioritized based on the one or more impacts, and wherein the graphical display also presents the one or more impacts and the one or more recommended actions, and wherein the one or more recommended actions are based on: the scope of responsibility for the user and the user role, and the one or more recommended actions are ranked based on the one or more impacts.