Patent Description:
Industrial process control and automation systems are often used to automate large and complex industrial processes. These types of systems routinely include various components including sensors, actuators, and controllers. The controllers typically receive measurements from the sensors and generate control signals for the actuators.

Process control and automation systems implemented as distributed control systems (DCS) are designed to control physical components with priorities given to system timing, deployment, availability, impact of failure, and safety. A typical DCS also has requirements to support longer component lifetimes, extensive patch verification and management, and different system operation expertise. These requirements may be implemented to avoid significant risk to the health and safety of human lives, serious damage to the environment, financial issues such as production losses, and negative impact to the economy.

[<NUM>] An example of a currently used system can be found in <CIT>. which discloses a flowmeter that includes a vibratable conduit, and a driver connected to the conduit that is operable to impart motion to the conduit. A sensor is connected to the conduit and is operable to sense the motion of the conduit and generate a sensor signal. A controller is connected to receive the sensor signal. The controller is operable to detect a single-phase flow condition and process the sensor signal using a first process during the single-phase flow condition to generate a validated mass-flow measurement. The controller is also operable to detect a two-phase flow condition and process the sensor signal using a second process during the two-phase flow condition to generate the validated mass-flow measurement.

This disclosure provides a system and method for ultrasonic flow meter prognostics with near real-time condition based uncertainty analysis.

In a first aspect of the invention, a method for ultrasonic flow meter prognostics according to claim <NUM> is provided.

In a second aspect of the invention, a system for ultrasonic flow meter prognostics according to claim <NUM> comprising at least one first processing device in a local environment and at least one second processing device in a cloud-based environment (<NUM>) is provided.

In a third aspect of the invention, a non-transitory computer readable medium according to claim <NUM> is provided.

Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and dependent claims.

The figures discussed below and the various embodiments 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.

<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> is used here to facilitate control over components in one or multiple plants 101a-101n. Each plant 101a-101n 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 101a-101n may implement one or more 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> is implemented using the Purdue model of process control. In the Purdue model, "Level <NUM>" may include 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 temperature, pressure, or flow rate. Also, the actuators 102b could alter a wide variety of characteristics in the process system. The sensors 102a and actuators 102b could represent any other or additional components in any suitable process system. 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 an Ethernet network, an electrical signal network (such as a HART or FOUNDATION FIELDBUS network), a pneumatic control signal network, or any other or additional type(s) of network(s).

In the Purdue model, "Level <NUM>" may include one or more controllers <NUM>, which are coupled to the network <NUM>. Among other things, each controller <NUM> may use the measurements from one or more sensors 102a to control the operation of one or more actuators 102b. For example, a controller <NUM> could receive measurement data from one or more sensors 102a and use the measurement data to generate control signals for one or more actuators 102b. Multiple controllers <NUM> could also operate in redundant configurations, such as when one controller <NUM> operates as a primary controller while another controller <NUM> operates as a backup controller (which synchronizes with the primary controller and can take over for the primary controller in the event of a fault with the primary controller). Each controller <NUM> includes any suitable structure for interacting with one or more sensors 102a and controlling one or more actuators 102b. Each controller <NUM> could, for example, represent a multi variable controller, such as a Robust Multivariable Predictive Control Technology (RMPCT) controller or other type of controller 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.

Two networks <NUM> are coupled to the controllers <NUM>. The networks <NUM> facilitate interaction with the controllers <NUM>, such as by transporting data to and from the controllers <NUM>. The networks <NUM> could represent any suitable networks or combination of networks. As particular examples, the networks <NUM> could represent a pair of Ethernet networks or a redundant pair of Ethernet networks, such as a FAULT TOLERANT ETHERNET (FTE) network from HONEYWELL INTERNATIONAL INC.

At least one switch/firewall <NUM> couples the networks <NUM> to two networks <NUM>. The switch/firewall <NUM> may transport traffic from one network to another. The switch/firewall <NUM> may also block traffic on one network from reaching another network. The switch/firewall <NUM> includes any suitable structure for providing communication between networks, such as a HONEYWELL CONTROL FIREWALL (CF9) device. The networks <NUM> could represent any suitable networks, such as a pair of Ethernet networks or an FTE network.

In the Purdue model, "Level <NUM>" may include one or more machine-level controllers <NUM> coupled to the networks <NUM>. The machine-level controllers <NUM> perform various functions to support the operation and control of the controllers <NUM>, sensors 102a, and actuators 102b, which could be associated with a particular piece of industrial equipment (such as a boiler or other machine). For example, the machine-level controllers <NUM> could log information collected or generated by the controllers <NUM>, such as measurement data from the sensors 102a or control signals for the actuators 102b. The machine-level controllers <NUM> could also execute applications that control the operation of the controllers <NUM>, thereby controlling the operation of the actuators 102b. In addition, the machine-level controllers <NUM> could provide secure access to the controllers <NUM>. Each of the machine-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to a machine or other individual piece of equipment. Each of the machine-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. Although not shown, different machine-level controllers <NUM> could be used to control different pieces of equipment in a process system (where each piece of equipment is associated with one or more controllers <NUM>, sensors 102a, and actuators 102b).

One or more operator stations <NUM> are coupled to the networks <NUM>. The operator stations <NUM> represent computing or communication devices providing user access to the machine-level controllers <NUM>, which could then provide user access to the controllers <NUM> (and possibly the sensors 102a and actuators 102b). As particular examples, the operator stations <NUM> could allow users to review the operational history of the sensors 102a and actuators 102b using information collected by the controllers <NUM> and/or the machine-level controllers <NUM>. The operator stations <NUM> could also allow the users to adjust the operation of the sensors 102a, actuators 102b, controllers <NUM>, or machine-level controllers <NUM>. In addition, the operator stations <NUM> could receive and display warnings, alerts, or other messages or displays generated by the controllers <NUM> or the machine-level controllers <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

At least one router/firewall <NUM> couples the networks <NUM> to two networks <NUM>. The router/firewall <NUM> includes any suitable structure for providing communication between networks, such as a secure router or combination router/firewall. The networks <NUM> could represent any suitable networks, such as a pair of Ethernet networks or an FTE network.

In the Purdue model, "Level <NUM>" may include one or more unit-level controllers <NUM> coupled to the networks <NUM>. Each unit-level controller <NUM> is typically associated with a unit in a process system, which represents a collection of different machines operating together to implement at least part of a process. The unit-level controllers <NUM> perform various functions to support the operation and control of components in the lower levels. For example, the unit-level controllers <NUM> could log information collected or generated by the components in the lower levels, execute applications that control the components in the lower levels, and provide secure access to the components in the lower levels. Each of the unit-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to one or more machines or other pieces of equipment in a process unit. Each of the unit-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. Additionally or alternatively, each controller <NUM> could represent a multivariable controller, such as a HONEYWELL C300 controller. Although not shown, different unit-level controllers <NUM> could be used to control different units in a process system (where each unit is associated with one or more machine-level controllers <NUM>, controllers <NUM>, sensors 102a, and actuators 102b).

Access to the unit-level controllers <NUM> may be provided by one or more operator stations <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

In the Purdue model, "Level <NUM>" may include one or more plant-level controllers <NUM> coupled to the networks <NUM>. Each plant-level controller <NUM> is typically associated with one of the plants 101a-101n, which may include one or more process units that implement the same, similar, or different processes. The plant-level controllers <NUM> perform various functions to support the operation and control of components in the lower levels. As particular examples, the plant-level controller <NUM> could execute one or more manufacturing execution system (MES) applications, scheduling applications, or other or additional plant or process control applications. Each of the plant-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to one or more process units in a process plant. Each of the plant-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system.

Access to the plant-level controllers <NUM> may be provided by one or more operator stations <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

At least one router/firewall <NUM> couples the networks <NUM> to one or more networks <NUM>. The router/firewall <NUM> includes any suitable structure for providing communication between networks, such as a secure router or combination router/firewall. The network <NUM> could represent any suitable network, such as an enterprise-wide Ethernet or other network or all or a portion of a larger network (such as the Internet).

In the Purdue model, "Level <NUM>" may include one or more enterprise-level controllers <NUM> coupled to the network <NUM>. Each enterprise-level controller <NUM> is typically able to perform planning operations for multiple plants 101a-101n and to control various aspects of the plants 101a-101n. The enterprise-level controllers <NUM> can also perform various functions to support the operation and control of components in the plants 101a-101n. As particular examples, the enterprise-level controller <NUM> could execute one or more order processing applications, enterprise resource planning (ERP) applications, advanced planning and scheduling (APS) applications, or any other or additional enterprise control applications. Each of the enterprise-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to the control of one or more plants. Each of the enterprise-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. In this document, the term "enterprise" refers to an organization having one or more plants or other processing facilities to be managed. Note that if a single plant 101a is to be managed, the functionality of the enterprise-level controller <NUM> could be incorporated into the plant-level controller <NUM>.

Access to the enterprise-level controllers <NUM> may be provided by one or more operator stations <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

Various levels of the Purdue model can include other components, such as one or more databases. The database(s) associated with each level could store any suitable information associated with that level or one or more other levels of the system <NUM>. For example, a historian <NUM> can be coupled to the network <NUM>. The historian <NUM> could represent a component that stores various information about the system <NUM>. The historian <NUM> could, for instance, store information used during production scheduling and optimization. The historian <NUM> represents any suitable structure for storing and facilitating retrieval of information. Although shown as a single centralized component coupled to the network <NUM>, the historian <NUM> could be located elsewhere in the system <NUM>, or multiple historians could be distributed in different locations in the system <NUM>.

In particular embodiments, the various controllers and operator stations in <FIG> may represent computing devices. For example, each of the controllers and operator stations could include one or more processing devices and one or more memories for storing instructions and data used, generated, or collected by the processing device(s). Each of the controllers and operator stations could also include at least one network interface, such as one or more Ethernet interfaces or wireless transceivers.

In particular embodiments, one or more of the sensors 102a could represent an ultrasonic flow meter. Ultrasonic flow meters have been in commercial use for a number of decades. In recent years, new type-testing standards were introduced for which flow meter manufacturers have seen mixed results (e.g., pass, partial pass, or failure). Under severe perturbated flow, some flow meters do not satisfy the requirements of the type-testing. Currently, within the global market, there is no near real-time condition based uncertainty analysis for an ultrasonic flow meter. Generally, diagnostics tools are available for a flow meter to determine a current operating state of the flow meter, but no prognostics tools exist that provide a detailed preventative maintenance intervention statement with calculated increasing condition based uncertainty (identifying the specific component of uncertainty). That is, no prognostics tools provide a prediction of the future state of the flow meter based on current or possible future conditions. Moreover, current diagnostics tools typically work on stranded physical assets. There is no dedicated virtual twin representing the physical flow meter for which scenarios modeling, to bring about new learning, can be performed without impacting the physical flow meter.

To address these and other issues, embodiments of this disclosure provide a cloud enabled system that generates data analytics that allow an operator or user to determine a meter's near real-time operational performance, and also generates domain specific analytics to generate prognostics data. The prognostics data provides an operator with information such as, "While the flow meter is working today, operation of the flow meter is likely to change on x date in the future based on possible conditions y and z. " The cloud enabled system also provides a virtual twin of the flow meter where testing can be performed in real-time or near real-time. In many cases, it is difficult or impossible to perform diagnostics on a physical meter currently operating in an industrial system. And because many industrial systems are <NUM>/<NUM>/<NUM> operations, there is little or no opportunity to take a flow meter out of operation to perform diagnostics. However, it is possible to change a virtual twin of the meter to perform such testing.

This disclosed embodiments provide for meter prognostics, provide a near real-time flow measurement condition based uncertainty analysis for one or more flow meters, and enable a virtual twin of a flow meter for domain specific analytics modelling to simulate the physical meter in a virtual environment. These provide a technical benefit over conventional testing and monitoring systems by enabling prognostics to avoid a meter failure event, and by providing near real-time flow measurement condition based uncertainty, thereby ensuring the best possible accuracy of the device. In addition, the disclosed embodiments enable a greater up-time (i.e., run-time or in-service time) of a flow meter while ensuring the lowest possible measurement condition based uncertainty and the highest quality process recipe.

As described in more detail below, various components in the system <NUM> could be designed or modified to support the cloud-enabled data analytics system according to this disclosure. For example, one or more of the operator stations <NUM>, <NUM>, <NUM>, <NUM> or one or more of the controllers <NUM>, <NUM>, <NUM>, <NUM> could be implemented in a cloud-based environment that communicates with one or more remotely-located controllers <NUM> or sensors 102a over a virtual private network (VPN) or other secure network.

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, servers, operator stations, networks, and other components. Also, the makeup and arrangement of the system <NUM> in <FIG> is for illustration only. Components could be added, omitted, combined, or placed in any other suitable configuration according to particular needs. 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 in which a cloud-enabled data analytics system can be supported. This functionality can be used in any other suitable system, and the system need not be related to industrial process control and automation.

<FIG> illustrates an example system <NUM> that uses a cloud-based control platform for flow meter prognostics and real-time condition based uncertainty analysis according to this disclosure. The system <NUM> includes various components that can be used in conjunction with an industrial process control and automation system, such as the system <NUM> of <FIG>. However, the system <NUM> can be used with any other suitable system or device.

As shown in <FIG>, the system <NUM> includes a local environment <NUM> and a cloud-based environment <NUM>. The local environment <NUM> includes local (e.g., onsite) components of an industrial process and automation system. For example, the components <NUM>-<NUM> may represent (or be represented by) corresponding components in the system <NUM> of <FIG>. The cloud-based environment <NUM> includes multiple components that can be located remotely from the local environment <NUM> and can communicate with the local environment <NUM> over a virtual private network (VPN) or other secure network. One or more of the components of the cloud-based environment <NUM> can include a computing device configured to perform some of the functions described below. In some embodiments, the computing device(s) of the cloud-based environment <NUM> could represent (or be represented by) one or more of the components of the system <NUM>, such as the controllers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>; the operations stations <NUM>, <NUM>, <NUM>, <NUM>; or the historian <NUM>.

The flow meter <NUM> is a ultrasonic flow meter that measures fluid flow in an industrial process. In some embodiments, the fluid is gas, although the fluid may be liquid or a combination of gas and liquid. The flow meter <NUM> can represent (or be represented by) one or more of the sensors 102a of <FIG>. In many systems, the flow meter <NUM> is part of a continuously-running system that is in a live operation state <NUM> hours/day, <NUM> days/year. Thus, outside of scheduled maintenance windows, it is a challenge for the flow meter <NUM> to be in an inactive state.

The analyzer <NUM> analyzes the constituent components of the fluid that flows through the flow meter <NUM>. That is, in a gas environment, the analyzer is a gas analyzer that determines and analyzes the constituent components of one or more gasses that flow through the flow meter <NUM>. In a liquid environment or a liquid-gas environment, the analyzer could be different and could analyze other components, including liquid components.

The pressure and temperature sensors <NUM> are sensors that measure pressure and/or temperature of a fluid (gas, liquid, or a combination of the two) in an industrial process. The pressure and temperature sensors <NUM> can represent (or be represented by) one or more of the sensors 102a of <FIG>.

The flow computer <NUM> receives data collected from the flow meter <NUM>, the analyzer <NUM>, and the pressure and temperature sensors <NUM>. The flow computer <NUM> may also act as a controller for one or more of the flow meter <NUM>, the analyzer <NUM>, and the pressure and temperature sensors <NUM>. The flow computer <NUM> can represent (or be represented by) one or more of the controllers <NUM> of <FIG>. In some systems, there is a flow computer <NUM> or controller for each flow meter <NUM>.

The metering supervisory computer (MSC) <NUM> collects and processes data from the flow computer <NUM> and other flow computers associated with other flow meters in the system <NUM>. The MSC <NUM> sends information about the flow meter <NUM> (e.g., bulk flow rate data, etc.) to the DCS <NUM>. In some embodiments, the MSC <NUM> is a supervisory control and data acquisition (SCADA) device or system. The MSC <NUM> may represent (or be represented by) one of the higher-level controllers <NUM>, <NUM>, <NUM>, <NUM> or one of the operation stations <NUM>, <NUM>, <NUM>, <NUM> of <FIG>.

The IIoT gateway <NUM> is a network gateway or router that operates in accordance with Industrial Internet of Things (IIoT) principles or protocols. The IIoT gateway <NUM> operates as a connection point between the local environment <NUM> and the cloud-based environment <NUM>. In some embodiments, the IIoT gateway <NUM> is configured as an edge gateway, which is a virtual router for virtual networks such as a VPN. The IIoT gateway <NUM> sends flow meter data to, and receives diagnostic, prognostic, and condition based uncertainty data from, the cloud gateway <NUM>. For example, the IIoT gateway <NUM> can receive validated bulk flow rate information <NUM> from the cloud gateway <NUM> and pass the validated bulk flow rate information <NUM> to a computing device (e.g., the MSC <NUM>) to determine the technically audited flow rate <NUM> (described in greater detail below), which is then sent to the DCS <NUM>.

The DCS <NUM> controls operations of the flow meter <NUM> and other components of the system <NUM>. The DCS <NUM> receives data from the MSC <NUM> and the technically audited flow rate <NUM>. Based on the received data, the DCS <NUM> can provide control instructions to the flow meter <NUM>, the analyzer <NUM>, the pressure and temperature sensors <NUM>, and other components of the system <NUM>.

The cloud-based environment <NUM> includes a cloud gateway <NUM>. The cloud gateway <NUM> is used to establish a connection between the local environment <NUM> and the cloud-based environment <NUM>, and serves as the entry point to the cloud-based environment <NUM>. In the system <NUM>, the cloud gateway <NUM> receives flow meter data from the IIoT gateway <NUM> and sends the flow meter data to one or more computing devices in the cloud-based environment <NUM>. The cloud gateway <NUM> also sends diagnostic, prognostic, and condition based uncertainty data to the IIoT gateway <NUM>. The cloud gateway <NUM> represents any suitable structure for establishing a connection between a local environment and a cloud-based environment.

The cloud-based environment <NUM> also includes a condition based monitoring (CBM) system <NUM>. The CBM system <NUM> performs CBM analysis on the flow meter data received from the local environment <NUM> through the IIoT gateway <NUM> and the cloud gateway <NUM>. CBM is a type of predictive maintenance that involves measuring the status of an asset (e.g., a flow meter) over time while it is in operation. The approach to CBM is one based on monitoring a number of variables within an asset where the variable is directly related to one or more technical parameters that have a correlation with the primary output from the asset (e.g., flowrate). For example, a "Signal Performance" variable could be determined as the "Valid Number of Samples" divided by the "Sample Rate" expressed as a percentage. As another example, a "Signal Strength Number" is derived from the inverse of the signal's power generator (i.e., gain control). The inference is that the higher the power the lower the signal strength number and the more challenging the signal's transmission across the measurement media in deriving flowrate.

The collected data can be used to establish trends, predict failure, and calculate remaining life of an asset. Using CBM, it is possible to perform maintenance only when the data shows that performance is decreasing or a failure is likely. Without CBM, preventative maintenance may be performed at specified intervals (sometimes unnecessarily), or may not be performed at all until a failure occurs. The CBM system <NUM> generates CBM data <NUM>, which may include data extracted from a process historian, such as the historian <NUM> of <FIG>. The combination of the CBM data and the historian data enables a subsequent analysis of the asset itself (e.g., flow meter) and its associated localized measurands from n-number of sensors. The sensors provide data that may directly influence the asset, thereby enabling a more thorough real-time uncertainty analysis.

A real-time uncertainty analyzer <NUM> in the cloud-based environment <NUM> takes the CBM data <NUM> and performs real-time uncertainty analysis on the CBM data <NUM>. The analysis of the CBM data <NUM> provides a mathematical confidence in the performance of the asset itself. To ensure the reliability of this data, the accuracy of the numerical analysis is verified through comparison between the calculated results of the numerical analysis and the actual CBM numerical data. To determine the uncertainty of the bulk output (e.g., flowrate) from the asset requires the additional step of the asset data plus its associated measurands to derive an uncertainty of the actual output (i.e., the resultant condition based uncertainty).

In a flow meter or other industrial instrument, condition based uncertainty analysis relates to assessing the uncertainty in a measurement of the instrument. Generally, device measurements can be affected by errors due to instrumentation, methodology, presence of confounding effects, and the like. Condition based uncertainty analysis provides an estimated confidence in the measurement. For example, for a flow meter, the output of the condition based uncertainty analysis is an uncertainty expression against a flow rate number (e.g., <NUM><NUM>/hour +/- <NUM><NUM>/hour, or can be expressed as a percentage such as <NUM><NUM>/hour +/- <NUM>%). In the system <NUM>, inputs to the real-time uncertainty analyzer <NUM> for the uncertainty analysis can include any and all data associated with the flow meter <NUM>, including the flow meter <NUM> itself, the analyzer <NUM>, the pressure and temperature sensors <NUM>, the flow computer <NUM>, other diagnostics, other measurands, or any combination of two or more of these. The output of the condition based uncertainty analysis in a validated bulk flow rate <NUM> with an uncertainty value (e.g., <NUM><NUM>/sec +/- <NUM><NUM>/sec). Such a condition based uncertainty value is novel for bulk flow rates. In conventional systems, the only generated data was a bulk flow rate, and it was not known how accurate the number was.

Condition based uncertainty analysis relies on large numbers of highly complex computations and requires substantial computational power, which is one reason why it is advantageous for the real-time uncertainty analyzer <NUM> to perform the computations in the cloud-based environment <NUM>, away from the physical environment. The cloud-based environment <NUM> provides a single, powerful computational environment that can be shared among many assets at many sites. This results in a much lower overall cost that providing such a computational environment at each site.

The validated bulk flow rate <NUM> with condition based uncertainty value is sent to the local environment <NUM> through the cloud gateway <NUM> and the IIoT gateway <NUM>. At a computing device in the local environment, a technical audit (e.g., a comparison of values) takes place between the values from the MSC <NUM> and the validated bulk flow rate <NUM>. If the comparison is good (e.g., the compared numbers are substantially the same-e.g., within <NUM>% of each other), then the flow rate is a technically audited flow rate <NUM> (i.e., it is validated, it is provable). The technically audited flow rate <NUM> is then passed to the DCS <NUM>. If the comparison is not good (e.g., the compared numbers are not substantially the same), then the data is not technically audited. Such data may be blocked, and a message can be generated that indicates the blocked data.

Once all of the data is collected, processed, and analyzed within the local environment <NUM> and the cloud-based environment <NUM>, it is not difficult to replicate the flow meter system and associated data in a virtual system for virtual modelling and testing. Performing virtual testing in a virtual system can reveal possible changes that, if made in the physical system, would lead to better results.

Accordingly, the cloud-based environment <NUM> includes a virtual twin instance <NUM> of the flow meter <NUM>. The virtual twin instance <NUM> allows a user (e.g., technician or engineer) to perform virtual modelling and testing that cannot be performed on the physical instance of the flow meter <NUM>. For example, the user can run scenarios in the virtual twin instance <NUM> that mimic and extrapolate changes that have been observed (or might be likely or possible) in the physical environment. The modeling can yield prognostics data <NUM> for the flow meter <NUM>. As used herein, prognostics can be defined as "an advance indication of a future event. " That is, prognostics allow a user to arrive at a prediction of a future event with some certainty. The prognostics data <NUM> is the culmination of the condition-based monitoring <NUM>, the condition based uncertainty analysis <NUM>, and the virtual twin <NUM>.

Here again, the cloud-based environment <NUM> is more suitable for the virtual modeling because the computational power required for the modeling is high and not suitable for installation at every site. Also, prognostics require performing a number of modelling scenarios and advanced analytics that cannot be run on a live physical flow meter.

<FIG> illustrates an example method <NUM> for flow meter prognostics and real-time condition based uncertainty analysis according to this disclosure. For ease of explanation, the method <NUM> is described as being performed using the system <NUM> of <FIG>. However, the method <NUM> could be used with any suitable device or system.

At step <NUM>, a computing device obtains flow measurement data from a flow meter in a local environment of an industrial process control system. This could include, for example, the flow computer <NUM> obtaining flow measurement data from the flow meter <NUM>.

At step <NUM>, a computing device in the local environment sends the flow measurement data to a cloud-based environment. This could include, the flow computer <NUM> or the MSC <NUM> sending the flow measurement data to the cloud gateway <NUM> in the cloud-based environment <NUM>.

At step <NUM>, a computing device in the cloud-based environment performs CBM analysis on the flow measurement data to determine CBM data. This could include, for example, the CBM system <NUM> performing CBM analysis on the flow measurement data.

At step <NUM>, a computing device in the cloud-based environment performs uncertainty analysis on the CBM data to determine a validated flow rate with an uncertainty value. This could include, for example, the real-time uncertainty analyzer <NUM> performing uncertainty analysis to determine the validated flow rate <NUM>.

At step <NUM>, a computing device in the local environment compares the validated flow rate to the flow measurement data in a technical audit to determine a technically audited flow rate. This could include, for example, the MSC <NUM> or another computing device determining the technically audited flow rate <NUM>.

At step <NUM>, a computing device in the local environment sends the technically audited flow rate to a DCS associated with the flow meter. This could include, for example, the MSC <NUM> sending the technically audited flow rate <NUM> to the DCS <NUM>.

At step <NUM>, the DCS controls operation of the flow meter based on the technically audited flow rate. This could include, for example, the DCS <NUM> controlling the flow meter <NUM> based on the technically audited flow rate <NUM>.

At step <NUM>, a computing device in the cloud-based environment generates prognostics data of the flow meter by performing prognostics analysis using the CBM data and a virtual twin instance of the flow meter. The virtual twin instance of the flow meter is configured with properties the same as the flow meter. This could include, for example, a computing device in the cloud-based environment <NUM> generating prognostics data <NUM> using the CBM data <NUM> and the virtual twin instance <NUM>.

At step <NUM>, the computing device sends the prognostics data of the flow meter to the DCS associated with the flow meter. This could include, for example, a computing device in the cloud-based environment <NUM> sending the prognostics data <NUM> to the DCS <NUM>.

Although <FIG> illustrates one example of a method <NUM> for flow meter prognostics and condition based real-time uncertainty analysis, various changes may be made to <FIG>. For example, while shown as a series of steps, various steps shown in <FIG> could overlap, occur in parallel, occur in a different order, or occur multiple times. Moreover, some steps could be combined or removed and additional steps could be added according to particular needs. In addition, while the method <NUM> is described with respect to the system <NUM> (which itself was described with respect to an industrial process control and automation system), the method <NUM> may be used in conjunction with other types of devices and systems.

<FIG> illustrates an example device <NUM> for performing functions associated with flow meter prognostics and real-time condition based uncertainty analysis according to this disclosure. The device <NUM> could, for example, represent the flow computer <NUM>, the MSC <NUM>, the DCS <NUM>, the historian <NUM>, another device shown or described in <FIG>, or a combination of two or more of these. The device <NUM> could represent any other suitable device for performing functions associated with flow meter prognostics and real-time condition based uncertainty analysis.

As shown in <FIG>, the device <NUM> can include a bus system <NUM>, which supports communication between at least one processing device <NUM>, at least one storage device <NUM>, at least one communications unit <NUM>, and at least one input/output (I/O) unit <NUM>. The processing device <NUM> executes instructions that may be loaded into a memory <NUM>. The processing device <NUM> may include any suitable number(s) and type(s) of processors or other devices in any suitable arrangement. Example types of processing devices <NUM> include microprocessors, microcontrollers, digital signal processors, field programmable gate arrays, application specific integrated circuits, and 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. In accordance with this disclosure, the memory <NUM> and the persistent storage <NUM> may be configured to store instructions associated with flow meter prognostics and condition based real-time uncertainty analysis.

The communications unit <NUM> supports communications with other systems, devices, or networks, such as the networks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. For example, the communications unit <NUM> could include a network interface that facilitates communications over at least one Ethernet network. The communications unit <NUM> could also include a wireless transceiver facilitating communications over at least one 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 performing functions associated with flow meter prognostics and real-time condition based uncertainty analysis, various changes may be made to <FIG>. Also, computing devices can come in a wide variety of configurations, and <FIG> does not limit this disclosure to any particular configuration of device.

In some embodiments, 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. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc, a digital video disc, or any other type of memory. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, e.g., a rewritable optical disc or an erasable memory 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. For example, "at least one of: A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and Band C.

The description in the present application should not be read as implying that any particular element, step, or function is an essential or critical element that must be included in the claim scope. The scope of patented subject matter is defined only by the allowed claims.

Claim 1:
A method for ultrasonic flow meter prognostics, comprising:
obtaining (<NUM>), by a first processing device, flow measurement data from a flow meter (<NUM>) in an industrial process control system;
sending (<NUM>), by the first processing device, the flow measurement data to a cloud-based environment;
performing (<NUM>), by a second processing device, condition based monitoring (CBM) analysis on the flow measurement data in the cloud-based environment (<NUM>) to determine CBM data (<NUM>);
performing (<NUM>), by the second processing device, uncertainty analysis on the CBM data (<NUM>) in the cloud-based environment (<NUM>) to determine a validated flow rate with an uncertainty value;
comparing the validated flow rate to the flow measurement data, by the first processing device, to determine (<NUM>) a technically audited flow rate (<NUM>);
sending (<NUM>), by the first processing device, the technically audited flow rate (<NUM>) to a distributed control system (DCS) (<NUM>) associated with the flow meter (<NUM>);
generating (<NUM>), by the second processing device, prognostics data (<NUM>) of the flow meter (<NUM>) in the cloud-based environment (<NUM>) by performing prognostics analysis using the CBM data (<NUM>) and a virtual twin instance (<NUM>) of the flow meter (<NUM>), the virtual twin instance (<NUM>) of the flow meter configured with the same properties as the flow meter (<NUM>); and
sending (<NUM>), by the second processing device, the prognostics data (<NUM>) of the flow meter to the DCS (<NUM>) associated with the flow meter (<NUM>).