Patent Description:
Industrial plants are large and complex installations. Process control systems give operators the means to monitor and control the process, e.g. by providing visualizations of the process and alarm management information, while process historians store the state of the system over time. Process visualizations typically depict parts of the process, often in a hierarchical way, showing e.g. dynamic process variables, trends and alarm states for a section of the process or for specific operator tasks. These process visualizations are based on engineering data and process models, and reflect e.g. the flow of information, material or energy in the process. Typically, though, the process topology information reflected in the process visualization is incomplete and fragmented, compared to the information contained in the engineering artifacts.

Monitoring the process allows the operator to diagnose abnormal situations and take corrective action. To mitigate production losses, the operator must rapidly assess the probable impact of the corrective action. However, the operator's ability to do so depends on their experience. Gaining experience in operating a specific plant often takes several years. For an inexperienced operator, it can be challenging to locate the required information in timely manner. Obviously, experienced operators are not available in greenfield plants. Even in brownfield plants, experienced operators leave and need to be replaced. Operator training simulators (OTS) can be used to provide a head start in operations, but these are expensive owing to the requirement for a high-fidelity process model. Instead, operations with limited efficiency in the early stages of operator training are often accepted.

For these reasons, owners of industrial plants face the risk of inefficient plant operations or even major incidents due to inexperienced operators.

<CIT> describes an analyzer arrangement for provision of information about a facility by means of root cause analysis.

<CIT> describes a method providing data for root cause analysis.

<CIT> describes a system receiving system fault codes, component fault codes, and failure modes.

There is therefore a need for affordable solutions that can support the inexperienced operator in making decisions relating to the operation of an industrial plant. This need is met by the subject-matter of the independent claims. Optional features are set forth by the dependent claims.

According to a first aspect, there is provided a decision support system according to claim <NUM>.

In one example the causal graph is a directed acyclic graph but it will appreciated that any probabilistic graphical model may be used to represent the conditional dependence between variables. The directed acyclic graph comprises a set of vertices or nodes representing variables in the industrial plant and a set of directed edges or arrows, each edge interconnecting two vertices. Each vertex represents an independent variable or a dependent variable. By "causal assumption" is meant that a causal relationship between two variables is assumed to exist but the causal relationship is not (yet) verified by the observational data. Reference is therefore made herein to possible (i.e. assumed or putative) causal relationships, as opposed to inferred causal relationships verified by the observational data. The causal assumptions are based on domain knowledge such as engineering data relating to the industrial plant. The causal graph may be built manually by e.g. a subject matter expert (SME) or automatically by e.g. a modeling tool, such as that described herein. One or more causal graphs may be used to capture all of the dependencies between variables in the industrial plant.

The observational data relates to prior operation of the industrial plant and may comprise collected or historical measurement data (e.g. from operation and/or commissioning) such as timeseries data relating to one or more (preferably all) of the variables represented by the causal graph. The observational data may thus be viewed as non-experimental data or empirical data. While experimental data obtained using interventions or high-fidelity simulations could also be used, it will be appreciated that this is not always possible or often prohibitively expensive.

According to the invention, performing the causal inference comprises: identifying the causal effect based on an input query; estimating the causal effect; validating the causal effect; and presenting the causal effect.

Identifying the causal effect may comprise finding all possible paths between two of the variables in the causal graph. For example, the input query (or estimand) may specify a causal relationship between the two variables for example in the form "Does variable B influence variable A?" or equivalent. In other words the query specifies one variable as an action, one variable as an outcome, and optionally one or more other variables e.g. as confounders. All possible ways in which B can have a causal effect on A are then identified. Invalid paths such as backdoor paths may be eliminated from consideration.

Estimating the causal effect comprises using conditional probabilistic formulae to estimate the strength of the causal relationship between the two variables. For example the formulae may comprise, for the two variables A and B in the input query,<MAT> where a confounder is a variable (measured or controlled) in the causal graph that influences both A and B. The strength is indicated by the difference between P1 and P2. The greater the difference between P1 and P2, the stronger the causal relationship. The decision support system may be configured to use methods to estimate the statistical significance of the difference between P1 and P2, including for instance one or more of propensity-based stratification, propensity score matching, inverse propensity weighting, regression, regression discontinuity. Further estimation methods will be apparent to the person skilled in the art. Additionally or alternatively, estimating the causal effect may comprise determining that no causal relationship exists between the two variables. For example, in response to determining that P1 equals P2 (e.g. if the difference does not exceed a predetermined threshold), no causal relationship can be inferred between A and B (in other words, every statistical relationship is explained by the confounders).

Validating the causal effect comprises performing data subset validation by reestimating the strength of the causal relationship using only a subset of the observational data (and validating the causal effect in response to there being no significant change in the causal effect) and/or performing placebo treatment by reestimating the strength of the causal relationship using observational data in which data including B is replaced with data in which B is not present (and validating the causal effect when the estimated strength drops to zero or thereabouts). Further validation methods will be apparent to the person skilled in the art.

Presenting the causal effect may comprise outputting the causal effect to the human plant operator for example by way of the HMI of the process control system or dashboard. Additionally or alternatively, presenting the causal effect may comprise outputting the causal effect to an entity performing automated or semi-automated operation of the industrial plant, such as an automated plant operation system, e.g. a reinforcement learning based plant operating agent.

The decision support system may be configured to perform root-cause analysis in relation to a given (measured) variable in the industrial plant to identify which of the other variables in the causal graph are most likely to influence the given variable. Root-cause analysis may be performed for the purpose of diagnosis when the given variable is found to be anomalous or to exhibit undesired behavior. The root-cause analysis may be repeated for some or all of the measured variables in the industrial plant, e.g. when anomalies are found in several measured variables.

In one example, performing the root-cause analysis for the given variable comprises: performing the causal inference to estimate the strength of the causal relationship between the given variable and each of the other variables. For example, where the industrial plant operates using process variables PV<NUM>-PVn, and where the given variable is PVi, performing the root-cause analysis may comprise performing the causal inference as described above using a plurality of input queries each specifying the given variable as outcome variable and one of the other variables as action variable. More particularly, for each of the other variables B = PV<NUM>. PVn not including the given variable A = PVi, the input query may take the form "Does variable B influence variable A?" or equivalent. The other variables may be ranked according to the strength of the respective causal relationships with the given variable. Identifying which of the other variables in the causal graph for the given variable are most likely to influence the given variable may comprise identifying the said other variable associated with the strongest causal relationship as the most likely root cause, or alternatively returning a list of the other variables ranked by the strength of their respective causal relationships with the given variable. Variables having no or only weak causal relationships with the given variable may be excluded.

Stated another way, performing the root-cause analysis may comprise defining a problem in terms of a value of the given variable satisfying a certain condition, and performing statistical estimation to calculate, for each of the other variables, a probability of the problem occurring given the observational data for that other variable. For example, performing the root-cause analysis may comprise evaluating P(A=a | do(B=b)) for each of the other variables B = PV<NUM>. PVn not including the given variable A = PVi, where "a" represents the problematic condition in the given variable A. The operator "do" is known in the art for simulating an intervention by reducing the observational data to include only that portion containing the stated value. The other variables may then be identified as likely root causes of the problem and/or ranked on the basis of the respective calculated probabilities. The condition may be for example that the value lies under or over a predetermined threshold or outside a predetermined range, for example where a temperature exceeds a threshold so as to be classified as a hotspot.

The decision support system may be configured to find corrective actions capable of effecting changes in a given measured process variable, for example by using the causal graph and the observational data to identify controlled variables in the industrial plant that exhibit a causal relationship with the given variable that should be corrected.

In one example, finding corrective actions comprises: performing the causal inference to estimate the strength of the causal relationship between the given variable and each of the other variables in the causal graph that is a controlled variable. For example, where the industrial plant operates using process variables PV<NUM>-PVn including at least one controlled variable C, finding corrective actions may comprise performing the causal inference as described above using for each controlled variable an input query specifying the given variable as outcome variable and the controlled variable as action variable, for example in the form "Does variable C influence variable A?" or equivalent, where C is the controlled variable C, where C != A, and where A = PVi. The controlled variables may be ranked according to the strength of the respective causal relationships with the given variable. The controlled variable associated with the strongest causal relationship may be identified for the corrective action, or alternatively a list of controlled variables may be identified optionally ranked by the strength of their respective causal relationships with the given variable. Variables having no or only weak causal relationships with the given variable may be excluded. Preferably the decision support system identifies as few corrective actions as possible that have the desired effect. The decision support system may be configured to use heuristics e.g. rule-based algorithms to select, exclude or prefer corrective actions, for example preferring setpoint changes over direct manipulation of actuators. What-if analysis may also be performed to eliminate corrective actions, as described below.

The decision support system may be configured to perform what-if analysis to identify one or more possible side effects of changing a controlled variable in the industrial plant. More particularly, performing the what-if analysis comprises: identifying in the causal graph a first variable A which is influenced by both second and third variables B and C which do not influence each other, and performing the causal inference to estimate the degree to which the causal effect of the second variable B on the first variable A is modified by the third variable C. For example, performing the what-if analysis may comprise evaluating P(A | do(B=b), C=c) for all values b of B while c remains constant. Here, the what-if query is: What if the controlled variable B is set to b while the value of another variable C is c? A is the first (dependent) variable, B is the second variable, and C is the third variable. The second variable B may be a controlled variable. In this way, side effects of varying the controlled variable can be determined, i.e. a determination is made as to the effect which the second variable B has on the first variable A while the value of the third variable C was c. The process may be repeated for each causal graph in which the controlled variable is represented to list all possible side effects of modifying the controlled variable. For example, for each graph in which the controlled variable is present, the input query may relate to whether the controlled variable has a causal effect on the dependent variable(s) of the causal graph. The results across all causal graphs constitute the list of possible side effects.

The decision support system may be configured to perform combinations of root-cause analysis, finding corrective actions and what-if analysis, optionally in a sequential manner. In one example, the decision support system is configured sequentially to perform: <NUM>) root-cause analysis to determine one or more candidate root causes for a process abnormality; <NUM>) finding corrective actions to identify controlled variables that could address the process abnormality; <NUM>) what-if analysis to explain what might happen when the controlled variables are changed, i.e. to analyse the possible side effects of the corrective actions. Corrective actions with few side effects may be preferred. The resulting corrective actions may be output to the operator and/or to the automated plant operation system.

According to a second aspect, there is provided a decision support method according to claim <NUM>.

The decision support system and method of the first and second aspects therefore improve plant efficiency despite operator inexperience, reduce dependency on operator cognitive state, and provide for more effective handling of complicated situations and faster resolution of operational issues. The operator is assisted in drawing conclusions regarding how issues are connected regardless of the physical distance between elements in the plant topology.

Finding possible root causes of problems assists the operator in evaluating possible mitigations, i.e. reasoning about the consequences of operator actions intended to remedy the problems. The decision support system helps the operator to better analyze the problems and to find the root causes more quickly. Less time is therefore required to achieve an understanding of the root causes of the problems so that they can be addressed quickly and correctly. The decision support system assists the operator in identifying the root causes of problems that might arise in the industrial plant with respect to time and topological dependencies, e.g. anomalies in valves.

Finding corrective actions increases plant reliability via effective and efficient problem-solving of abnormal situations.

What-if analysis enables the operator to take faster and more informed decisions about corrective actions with fewer undesired side effects by explaining the context and forecasted consequences of the corrective actions.

Furthermore, the decision support system facilitates autonomous plant operation using artificial intelligence or otherwise automated plant operation systems by identifying root causes of problems and selecting corrective actions efficiently.

As mentioned above, the causal graph (or any probabilistic graph) may be modeled using domain knowledge including engineering data such as plant topology data, process model data, and control narratives.

According to a third aspect, there is provided a computer-readable medium according to claim <NUM>.

A detailed description will now be given, by way of example only, with reference to the accompanying drawings, in which:-.

<FIG> schematically illustrates an industrial plant <NUM> carrying out an industrial process <NUM>. The process <NUM> is influenced by process equipment <NUM> (such as actuators) which receives as input control signals specifying a plurality of controlled variables (such as actuator values or setpoints) CPV<NUM>, CPV<NUM>. Sensors <NUM> provide feedback on the process <NUM> in the form of a plurality of measured variables MPV<NUM>, MPV<NUM>. Together the controlled and measured variables may be referred to as process variables PV (PV<NUM>, PV<NUM>. A process control system <NUM> receives the feedback from the sensors <NUM> and outputs the control signals to the process equipment <NUM> so as to influence the process <NUM> in such a way as to produce the desired product, as is known in the art.

According to the present disclosure, the industrial plant <NUM> further comprises a decision support system <NUM> configured to: obtain a causal graph <NUM> modeling causal assumptions relating to conditional dependence between variables in the industrial plant <NUM>; obtain observational data <NUM> relating to operation of the industrial plant <NUM>; and perform causal inference using the causal graph <NUM> and the observational data <NUM> to estimate at least one causal effect <NUM> relevant for making decisions when operating the industrial plant <NUM>.

Although only one causal graph <NUM> is illustrated and described, several causal graphs may be used to represent the industrial process <NUM>. The causal graphs <NUM> are i) provided manually by human experts, ii) automatically derived from engineering data <NUM> (as described further below), or any combination of the two methods. The causal graph <NUM> describes how the variables PV in the process <NUM> might influence one another. In the causal graph <NUM>, a directed edge to a variable A from another variable B denotes that a causal relationship from B to A is expected.

Using the causal graph <NUM>, supplemented by the observational data <NUM>, the decision support system <NUM> performs causal inference to help the human operator or automated plant operation system in three use cases: (<NUM>) finding root causes; (<NUM>) finding corrective actions; and (<NUM>) what-if analysis to perform sanity checks before corrective actions are executed. Causal inference serves to ascertain whether a causal assumption is present in the observational data.

<FIG> is a flowchart representing a method <NUM> of performing causal inference. Performing the causal inference comprises: identifying <NUM> the causal effect <NUM> based on an input query <NUM>; estimating <NUM> the causal effect; validating <NUM> the causal effect; and presenting <NUM> the causal effect.

In other words, in step <NUM> the causal graph <NUM> is used to decide which conditional effects (probabilistic influences) need to be taken into account when in step <NUM> the strength of causality is estimated. In step <NUM>, the estimation can be tested regarding its sensitivity. At step <NUM>, the method returns an indication as to whether variable A is actually influenced by variable B.

Starting from the causal graph <NUM>, describing assumed causal relationships between process variables including control variables such as setpoints or actuator values, the inference requires a causal relationship to be checked. In this regard, the input query <NUM> is provided in the form of "Does variable B influence variable A".

After finding all possible paths from B to A in the causal graph <NUM> in step <NUM>, two conditional probabilistic formula are used in step <NUM> to determine whether there exists a causal relationship between A and B:<MAT> where confounders are all process and controlled variables that influence both A and B. If P1 equals P2 then there is no causal relationship between A and B (every statistical relationship is explained by the confounders) and if P1 does not equal P2 there is a causal relationship. The more different P1 is to P2, the stronger the relationship. Possible methods to estimate the statistical significance of the difference between P1 and P2 are for instance propensity-based stratification, propensity score matching, inverse propensity weighting, regression, regression discontinuity.

Step <NUM> tests the strength and validity of the causal relationship found in the previous steps. Possible approaches are using only a subset of data to test the relationship (which should yield a similar result) or (in experimentation) using a placebo treatment (replacing data where B is present with data where B is not present).

For diagnosis and root-cause analysis, the causal graph <NUM> and the observational data <NUM> are used by the decision support system <NUM> to identify possible causes of an anomaly in one or several process values. For each process value, one causal graph <NUM> may be used. Additionally or alternatively, there may be one causal graph covering the whole process <NUM>.

To infer possible root-causes for anomalies or undesired behavior of certain process variables PV<NUM>. PVn, the causal graphs <NUM> for each process variable are analyzed according to the method described above in relation to <FIG>. The input query <NUM> is repeated for every variable B that is not equal to A = PVi. The results of repeating the process across PV<NUM>. PVn are integrated by searching for possible causes across PV<NUM>. PVn to find the most likely root-cause. In addition, regression can be used to determine the direction of influence.

Moreover, topology data can be used to refine the root-cause analysis. For example, where the root-cause analysis identifies one variable (e.g. a controlled temperature) in the causal graph as a root cause, topology data may be used to identify factors contributing to that variable at an asset level going beyond the process level of the causal graph (for example the motor of a cooling unit controlling that temperature).

For identifying corrective actions, the causal graph <NUM> and the observational data <NUM> are used to identify controlled process variables that exhibit a causal relationship with a measured process variable that should be corrected.

To infer corrective actions, the process is similar to the root-cause analysis described above. The causal graphs <NUM> of PV<NUM>. PVn that should be manipulated are analyzed (e.g. those process variables PV that were determined to be possible root-causes in the root-cause analysis). This time, not all variables B != PVi are checked for a causal relation, but only controlled variables C that can be altered by the operator or the plant operating system (e.g. setpoint of control loops, actuator values). Again, the results across PV<NUM>. PVn are integrated in order to find as few corrective actions as possible that have the desired effect. Heuristics can be used to suggest or select actions, for instance preferring setpoint changes (where a controller manages the desired effect) over direct manipulation of actuators.

For what-if analysis (identifying side effects), the same causal graph <NUM> and the observational data <NUM> that were used to infer root-causes are used. In root-cause analysis, we ask the question: was it the change observed in one variable that caused an effect in another? Whereas, in the what-if analysis, we ask the question as: what if a value of one variable (i.e., a setpoint related to that variable) were changed?.

When variable B influences variable A, the degree to which B influences A may be different for different values of a third variable, C. Variable B may be a controlled variable controlled using a setpoint or actuator value, or a variable influenced by such a controlled variable. In other words, changes in variable B's effect on variable A may be observed differently due to, say, different levels of valve closing. To infer what happens to variable B's effect on variable A when variable C is is set to a particular value, the same causal graphs <NUM> and the observational data <NUM> are used. The causal graph <NUM> of the process variable A is analyzed and P(A | do(B=b), C=c) is evaluated where the value of "c" is fixed (the 'what-if value'), and B is a variable that impacts A but is invariant itself when C=c (i.e., B is not affected by C). For each causal graph <NUM> in which the variables are present, the input query <NUM> asks whether the controlled variable B has a causal relation with the dependent variable A of the causal graph <NUM> while C=c. The results across all graphs constitute the list of possible side effects.

The steps can be also combined in a sequential manner:-.

Example use cases will now be described with reference to <FIG>, which shows a topology graph for a data center, and to <FIG>, which illustrates a causal graph derived from the topology graph with the help of a Subject Matter Expert (SME) or learned from engineering data (e.g., by using propensity-based technique, covariate matching etc.), or using both the SME knowledge along with the engineering data. The causal graph is a directed acyclic graph comprising a set of vertices and a set of directed edges between the vertices.

The data center has a racks of servers and air conditioning units that push cold air to regulate temperature in the servers. At times, hotspots may arise in the aisles of the data center. A hotspot may be caused for various reasons. For example, a fault in the motor that powers the cooling fan that regulates the flowrate of the cold air can lead to a lack of cold air in the data center aisles and subsequently to creation of a hotspot. Or, the chiller might not be functioning properly and the supply-air temperature might not be sufficiently cold to avoid a hotspot in an aisle. Similarly, a hotspot may be created if there is overload on certain servers in an aisle due to inequitable application deployment.

In a first example use case, root-cause analysis (RCA) is performed. A hotspot is detected in the aisle temperature measured near a set of servers. An RCA input query is formulated as: does the cooling unit fan speed (variable B) influence the aisle temperature (variable A)? Since there are no confounders in this example, possible variables of interest for the root-cause analysis are:.

Given the topology graph along with the causal graph, we analyze the impacted variable's causal graph (i.e., aisle temperature's causal graph) to perform further analysis in relation to each causal variable. Assuming for convenience that the servers load is constant, statistical estimation can be performed on the observational data for the following variables:.

The values "fr" and "t" may be selected based on operator experience and/or using values in the neighbourhoods of known setpoints, to investigate what might happen if the setpoints were altered. Ranked by the probabilities, a list of most-likely root causes is obtained indicating for example that the cooling unit fan motor might not be working properly, or the chiller may not be well regulated.

In a second example use case, corrective actions are found. The input query here may take the form: does a setpoint change for the supply-air flowrate (control variable) influence the aisle temperature (hotspot)? The probabilistic analysis procedure is similar to RCA except that for finding a corrective action only control variables are considered. Continuing with the example shown in <FIG> and <FIG>, based on the causal graph, the causal effect may be estimated as in the RCA example, and then the supply-air temperature setpoint may be reduced, or the supply-air flowrate setpoint may be increased.

In a third example use case, what-if analysis is performed to determine the degree to which the causal effect of the supply-air flowrate on the hotspot is modified by the supply-air temperature. Changes in the supply-air flowrate (SFR) are observed due to changes in the cooling unit fan speed. The causal graph is observed for the hotspot i.e., aisle temperature. Pr(hotspot|do(SFR=f), SAT=t) is then estimated for all possible supply air temperature (SAT) values. The value "f" may again correspond to a value at or around a setpoint.

Referring again to <FIG>, also shown is a modeling tool <NUM> for building the causal graph <NUM> using the engineering data <NUM> and observational data <NUM>. The causal graph <NUM> is then provided to the decision support system <NUM>.

The causal graphs <NUM> capture the relationships between measured and controlled variables in the process <NUM>. There might be more than one causal graph <NUM> to capture the process <NUM>, e.g. one graph for each of the process variables PV (including process KPI) modelling each PV as a dependent variable. The information provided in the causal graph <NUM> may be qualitative (there is a relationship) rather than quantitative (how strong the relationship is and whether it is positive or negative). According to the present disclosure, graph based models are first used to select a set of relevant measurements (e.g. going from hundreds of candidates down to a few) before the above-mentioned methods are performed to refine the network structure and estimate the strength of the relationships in terms of conditional probabilities.

Referring now to <FIG>, the modeling tool <NUM> may be configured to combine engineering data <NUM> e.g. plant topology and process model data with the observational data <NUM> from process control and monitoring. More particularly, the modeling tool <NUM> may combine process topology information and process control configuration with information about process state (including past and present measurements), history, and alarm and event data. In this way, dynamic information from the process control system <NUM> and static information about the process topology, e.g. the possible flow of information, material or energy in the process <NUM> may be combined. Preferably the process topology information is available in a machine-readable form that is up-to-date.

The modeling tool <NUM> may be configured (using e.g. programming interfaces to relevant components of the process control system <NUM>) to:.

The resulting causal graphs may be used as input for the above-described tool-based analysis of the plant <NUM>, or to provide data for e.g. time-series analysis or machine learning algorithms for root cause and failure path detection. For example, causal graphs based on topology may be used to perform computational expensive analysis like transfer-entropy, or to create predictive models that determine influence in a given situation.

In this way, (qualitative) models of the process <NUM> may be created, without needing to rely on the expertise of an SME, that can help predict consequences of possible operator actions on relevant parts of the process <NUM>.

The models e.g. causal graphs may be further used to parameterize and initialize (quantitative) simulation models that can offer impact calculations in the form of predictions of consequences of possible operator actions on relevant parts of the process <NUM>. The simulation models can be used to identify possible user inputs (plant elements that have a causal influence on the abnormal situation, e.g. derived from the causal graph) that can change the current situation. The list of these input values may be used to create simulation experiments in which these values are changed in order to quantify the effect on the process state, e.g. to avoid triggering of alarm limits and system trips.

The modeling tool <NUM> and/or the decision support system <NUM> may allow user manual editing of the displayed results and offer feedback on automatic analysis of abnormal situations and their root causes. A log of the user interactions with the system can be mined for improving the performance and better meeting user expectations.

The causal graphs thus created may be used in the ways described above to identify parts parts of the process state relevant for a specific situation under investigation. This subset of the available process state information augmented with the relevant topology information may then be used to guide and focus the above-described tool-assisted analysis of the situation towards efficient and effective solution for root-cause problems. The parts of the process state may concern topology information and/or information such as system alarms or signals/measurments from control loops or instruments that are relevant for the specific situation. "Relevant" can be defined in that the part is linked to the situation (that is, abnormal signal shapes or alarms) with a probability above a corresponding threshold probability.

Although the decision support system <NUM> and modeling tool <NUM> are shown as separate, individual units, it will be appreciated that these systems may form part of the same unit, such as the process control system, and that these systems could be distributed systems.

Referring now to <FIG>, a high-level illustration of an exemplary computing device <NUM> that can be used in accordance with the systems and methodologies disclosed herein is illustrated. The computing device <NUM> includes at least one processor <NUM> that executes instructions that are stored in a memory <NUM>. The instructions may be, for instance, instructions for implementing functionality described as being carried out by one or more components discussed above or instructions for implementing one or more of the methods described above. The processor <NUM> may access the memory <NUM> by way of a system bus <NUM>. In addition to storing executable instructions, the memory <NUM> may also store conversational inputs, scores assigned to the conversational inputs, etc..

The computing device <NUM> additionally includes a data store <NUM> that is accessible by the processor <NUM> by way of the system bus <NUM>. The data store <NUM> may include executable instructions, log data, etc. The computing device <NUM> also includes an input interface <NUM> that allows external devices to communicate with the computing device <NUM>. For instance, the input interface <NUM> may be used to receive instructions from an external computer device, from a user, etc. The computing device <NUM> also includes an output interface <NUM> that interfaces the computing device <NUM> with one or more external devices. For example, the computing device <NUM> may display text, images, etc. by way of the output interface <NUM>.

It is contemplated that the external devices that communicate with the computing device <NUM> via the input interface <NUM> and the output interface <NUM> can be included in an environment that provides substantially any type of user interface with which a user can interact. Examples of user interface types include graphical user interfaces, natural user interfaces, and so forth. For instance, a graphical user interface may accept input from a user employing input device(s) such as a keyboard, mouse, remote control, or the like and provide output on an output device such as a display. Further, a natural user interface may enable a user to interact with the computing device <NUM> in a manner free from constraints imposed by input device such as keyboards, mice, remote controls, and the like. Rather, a natural user interface can rely on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, machine intelligence, and so forth.

Additionally, while illustrated as a single system, it is to be understood that the computing device <NUM> may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device <NUM>.

Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer-readable storage media. A computer-readable storage media can be any available storage media that can be accessed by a computer. By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc (BD), where disks usually reproduce data magnetically and discs usually reproduce data optically with lasers. Further, a propagated signal is not included within the scope of computer-readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included in the definition of communication medium.

Claim 1:
A decision support system (<NUM>) for an industrial plant (<NUM>), the decision support system (<NUM>) being configured to:
obtain a causal graph (<NUM>) modeling causal assumptions relating to conditional dependence between variables in the industrial plant (<NUM>);
obtain observational data (<NUM>) relating to operation of the industrial plant (<NUM>); and
perform causal inference using the causal graph (<NUM>) and the observational data (<NUM>) to estimate at least one causal effect (<NUM>) relevant for making decisions when operating the industrial plant (<NUM>),
characterized in that performing the causal inference comprises: identifying the causal effect (<NUM>) based on an input query; estimating the causal effect; validating the causal effect (<NUM>); and presenting the causal effect (<NUM>),
wherein estimating the causal effect (<NUM>) comprises using conditional probabilistic formulae to estimate the strength of the causal relationship between two of the variables,
wherein validating the causal effect (<NUM>) comprises performing data subset validation by reestimating the strength of the causal relationship using only a subset of the observational data and/or performing placebo treatment by reestimating the strength of the causal relationship using observational data (<NUM>) in which data including a variable is replaced with data in which the same variable is not present.