The present invention relates to control systems, particularly but not exclusively to closed loop control systems such as those for HVAC (heating ventilation and air conditioning) systems which may include components such as boilers and/or air conditioning units.

Conventional control systems have sensors monitoring the outputs of a process or system and a controller which takes the sensor outputs and a reference signal giving a desired state (for example a set temperature) and generates control outputs which drive the process or system to achieve the desired state.

Such control systems, or the process or system (for example a boiler) may fail or the operation may be degraded and thus it is known to include some validation and self- diagnosis or fail-safe features in each element, ranging in complexity from a gross over- temperature cutout in the case of a boiler to software diagnosis components.

Notwithstanding the known steps taken to improve control system accuracy and reliability or identify faults, problems occur in real life installations, particularly as systems age over time and individual components are installed in more complex systems (such as the heating system of a building) which may in itself contribute to problems.

The Internet of Things (loT) means smart devices are often installed and remotely operated by non-professionals and the performance of these devices may require monitoring. This monitoring typically involves the real-time evaluation of operational aspects of the control system associated with these devices. Causes of abnormal functioning of these control systems may include incorrect installation, unexpected inputs, decaying components and inappropriate usage. It is useful to be informed of abnormal or incorrect functioning to prevent problems ranging from customer dissatisfaction to safety hazards. There is described herein a diagnostics tool and method which may be used for recognising or highlighting anomalous behaviour of a closed-loop control system in real- time. Thus problems may be identified before reaching a state from which it is hard to recover (e.g. a “fatal” state), which may provide timely information for customers/experts/operators and may allow them to take appropriate actions. The system/method may also be used to identify less critical situations, such as subtle anomalies that are not necessarily critical states. Human action (or otherwise) is not always needed/appropriate when anomalous behaviour is detected, for example in some cases a response may be provided automatically.

Many conventional monitoring techniques are based on a real-time analysis of the difference between (desired) set point values and observed output values as measured by one or more sensors (sometimes known as the‘error signal’). Alternatively, the operational state of the control system may be inferred exclusively from the observations of the output signal. However, the error signal may not always be the most representative quantity to consider for diagnosing performance of the control system as a whole; and, similarly, sensor data alone may not give a complete picture.

Computational models and machine learning algorithms can be employed to design a control system, analyse its characteristics and assist in the control itself. Some of the embodiments described herein may enable real-time diagnosis of control systems in a non-intrusive, sensor-data-driven, self-learning and process-independent way.

Aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims.

There is described herein a diagnostic apparatus for a closed loop control system, the closed loop control system comprising: a process or system having at least one actuating module and an operation at least a part of which is controlled by the or each actuating module; at least one sensor monitoring the state of the process or system to generate at least one sensor signal; a controller arranged to receive one or more reference signals defining a desired state of the process or system and the or each sensor signal and to generate respective control signals for the or each actuating module to drive the process or system towards the desired state, the diagnostic apparatus comprising: system state detection apparatus arranged to receive the or each sensor signal; controller state detection apparatus arranged to receive the or each control signal; an estimation module arranged to compute an expected control signal for the or each control signal from the received sensor signals; an anomaly detection module arranged to detect a possible anomaly based on determining a difference between the expected control signals and the received control signals.

Thus the diagnostic apparatus operates independently from the controller and actuating module and system under control (and in parallel with any conventional fault detection apparatus) and operates by predicting what it would expect the controller to be doing in a particular system state and noting a discrepancy. Importantly the diagnostic apparatus does not form part of the controller or adjust the control loop or serve as a failover but acts as an“observer”.

Since the diagnostic apparatus, by reverse engineering, or reconstructing, the control signal, can map expected outputs to inputs and thereby detect an anomaly or unexpected behaviour, this can be a more efficient way of detecting differences.

Since the diagnosis is based on comparing (numerical) values of the actual and expected control signals it may be possible to detect anomalies more simply and/or accurately, for example because control signals may be bounded whereas observations of parameters affected by the control system/process (e.g. temperature, in the context of HVAC) are not. It may also be possible to detect errors or faults earlier by looking at the control signal, rather than e.g. observing parameters that may be affected by the control system/process as this may result in a time lag before the effects of an erroneous control signal can be observed.

Furthermore, by comparing actual control signals with expected control signals received from sensor signals, the apparatus may be able to perform the check/diagnosis without specific contextual knowledge or simulation of the control system itself, for example by basing the expected control signal on historical control signal data. Such historical control signal data may be numerical, and in most cases it will be bounded (normally taking on discrete values). Historical control signal data may, for example, include the control signal values and the sensor signal values for a historical time period. A model may then be built to compute control signals that are to be expected for given sensor values. The diagnostic apparatus may be provided as a dedicated independent hardware apparatus (with embedded software) which connects to an existing system without affecting the control operation at all. However in some cases, where the existing controller is implemented in software or partially in software, some or a part of the diagnostic apparatus may be embodied in the form of software running on the same processor in order to detect the sensor signals or control signals fed into or generated by the controller.

The estimation module may be arranged to compute (e.g. estimate or predict) an expected, or estimated, control signal for a future, past or present control signal. As such the prediction is not limited to being only a future/current prediction but could be a prediction of control signals which have previously been provided or generated by the controller.

The process or system will generally have an actuator or actuating module, however this is not essential. The actuating module may be provided in the form of a software module or component arranged to be controlled by the controller, although it can be a physical device or appliance. The presently described diagnostic apparatus can be applied to practically any control system or process because it is defined by inputs and outputs and a system function (or transfer function), so it does not require details of the workings of the system or the arrangement or even existence (or non- existence) of any actuator(s).

In some embodiments there will not be a physical sensor device in the control process/system, e.g. in a software implementation. However there will generally be some measure of one or more outputs of the control system which are expressed in a signal (equivalent to the“sensor signal” described above) and used in the diagnostic method to predict control signals.

Preferably the estimation and/or anomaly detection module employs a learning algorithm to predict or compute the expected control signals and/or identify anomalies based on the historical behavior of the system, and in particular historical control signals.

The learning algorithm may be based on a Bayesian approach or a neural network or a Support Vector Machine. Preferably the learning algorithm is arranged to learn the behavior of a system to which it is connected in a first phase, or initial time period (e.g. a“learning” period), in which a threshold for signaling a possible anomaly is relatively high and then to operate in a second/subsequent phase, or“trained” period, in which a threshold for signaling a possible anomaly is relatively low.

Thus the 'tolerance' of the diagnostic tool can be adjusted so that the predictions (or reconstructions) of the diagnostic tool will become more accurate as more historical data of the system's behaviour becomes available. Thus it may be possible to detect anomalies with a higher confidence once more training data is available and so the signaling threshold may be adjusted accordingly (e.g. so that false alarms early on are avoided).

Preferably, the anomaly detection module is arranged to detect a possible anomaly based on one or more criteria and the one or more criteria varies dependent on the amount of historical behaviour data input into the learning algorithm, preferably such that a threshold for detecting a possible anomaly based on the difference between the expected control signals and the received control signal is lower when more historical behaviour data has been input into the learning algorithm.

Optionally, the anomaly detection module is arranged: during the first phase, to detect a possible anomaly based on one or more initial criteria; and during the second, to detect a possible anomaly based on one or more trained criteria, the one or more trained criteria being different from the one or more initial criteria, preferably wherein the one or more trained criteria have a lower threshold than the one or more initial criteria.

Preferably the apparatus further comprises: reference state detection apparatus arranged to receive the one or more reference signals; and the estimation module is arranged to predict or compute the expected control signal for the or each control signal from the received reference signals. Thus a preferred setpoint or reference value for the system or process may also be factored into the diagnosis. For example, different control signals may correspond to different reference signals.

The anomaly detection module may be arranged to detect a possible anomaly based on determining a difference between the expected control signals and the received control signals as a function of time. Thus changes or trends in the difference may be identified. For example, if the difference is greater than a difference threshold for more than a predetermined difference time, then an anomaly may be identified or detected. In some cases a differential of the difference, e.g. the rate of change of the difference, may be used, for example an anomaly may be identified if the difference is increasing at more than a predetermined threshold rate. In one example, a rate of change in the difference being above a certain threshold may lead to detection of an anomaly, even if the actual/absolute difference between the expected and received control signals is not above the difference threshold for more than a predetermined difference time since this could indicate that the control system could be quickly moving into an undesirable state and corrective action may be required promptly.

The control signal may be chosen or selected in an appropriate format which may make it easier to interpret and to set meaningful parameters/criteria for anomaly detection. In some examples, the expected control signals are bounded within a control signal range. For example, the control signal range may be from 0 to 1.

The received control signals may also be bounded within a control signal range, preferably the same range as for the expected control signals. For example the control signal range may be from 0 to 1. Sometimes the control signals received from the control system will already be bounded (e.g. the controller itself may use such bounded control signals). However in other embodiments the diagnostic apparatus may be configured to convert the received control signal to an appropriate format, such as into a normalised format.

For example, the diagnostic apparatus may further comprise a normalising module arranged to normalise the received control values, preferably by normalising the control values within a range from 0 to 1.

In some embodiments, the diagnostic apparatus further comprises: an alert apparatus arranged to output an alert based on the detection of a possible anomaly by the anomaly detection module.

Preferably the alert apparatus is arranged to output the alert as a message sent to a user, such as to a smartphone, tablet or computer. For example the message may be sent to a user of the system or process and/or to an administrator, engineer or manufacturer. The message may be sent via a WAN network, e.g. the Internet. The message may be sent to a cloud server, which may store information on multiple control systems/processes, optionally located across different locations. The message may e.g. be used to update a diagnostic status for the controller, or control system or process, which may be stored on the cloud server.

Preferably the anomaly detection module is arranged to detect a possible anomaly based on determining that at least one difference between an expected control signal and a corresponding received control signal is greater than a threshold difference. The threshold difference may be a predetermined value. Where the control signals are binary, the threshold difference may simply be anything greater than zero (e.g. because the control signal can only take one of two values). Thus it may be possible to identify anomalies where control signals diverge by more than this threshold from the expected control e.g. a significant divergence. The threshold difference value may vary. For example, the threshold difference value may decrease as more historical data about the system is received or collected.

Optionally, the anomaly detection module is arranged to detect a possible anomaly based on determining that at least one difference between an expected control signal and a corresponding received control signal persists for more than a threshold time period. Thus transient divergences from the expected control may not immediately trigger an error, whereas persistent and/or continuous divergences may. Preferably the threshold time period is predetermined. In some embodiments the anomaly may be detected if the difference exists continuously over the time period, preferably the difference is higher than the threshold for the time period. Depending on the application, the threshold time period may be greater than 10 seconds, greater than 20 seconds, greater than 30 seconds and/or greater than 1 minute or 5 minutes. Sometimes the threshold time period may be less than 1 hour, less than 30 minutes and/or less than 10 minutes, or less than 1 minute or less than 30 seconds.

In some embodiments, the anomaly detection module is arranged to detect a possible anomaly based on determining that at least one difference between an expected control signal and a corresponding received control signal is non-zero and/or above a threshold difference for more than a threshold proportion of time within a (predetermined) time period. For example, this may be determined by looking at a rolling proportion value of the differences in control signals over a predetermined time period e.g. an immediately preceding time period. The predetermined time period may be around 1 hour, 1 minute, around 2 minutes or around 5 minutes. The time period may be greater than 10 seconds or greater than 30 seconds. The time period may be less than 5 hours, less than 4 hours, less than 2 hours or less than 30 minutes. The threshold proportion may be greater than and/or around 10%, 20% and/or 30%. In some cases the threshold proportion may be greater than and/or around 50% or even around 70% or 80%. Thus it may be easier to detect persistent divergences from the predicted signals.

Preferably, the anomaly detection module is arranged to detect a possible anomaly based on determining that the average value over a time period of at least one difference between an expected control signal and a corresponding received control signal is above a threshold average difference, preferably wherein the average value is above a threshold average difference for more than a threshold proportion of time within a (predetermined) time period. The predetermined time period may be around 1 hour, 1 minute, around 2 minutes or around 5 minutes. The time period may be greater than 10 seconds or greater than 30 seconds. The time period may be less than 5 hours, less than 4 hours, less than 2 hours or less than 30 minutes.

In some embodiments, the diagnostic apparatus further comprises: a correction apparatus arranged to provide one or more corrective actions in response to the detection of an anomaly by the anomaly detection module. The correction apparatus may be arranged to provide corrective action for all“possible” anomalies detected, or it may perform corrective action only if further confirmation is obtained, e.g. stricter criteria are met, such as a difference being greater than a correction threshold (which may be greater than a threshold difference for detecting a possible anomaly), or if an anomaly criterion (e.g. a threshold, which may be the same as the threshold for detecting a possible anomaly) has been met for more than a predetermined amount of time, e.g. a correction time threshold.

Preferably the one or more corrective actions include on or more of: replacing the controller; altering a state or configuration or operating condition of the controller; and discontinuing operation of the controller or control system. For example, the correction apparatus may replace the controller by sending a message to the controller exhibiting anomalous behaviour to stop or pause its operation and to another controller to take over from the initial controller. In software applications, replacing the controller may be by replacing a section of code used to control the system.

Providing the corrective actions may involve the corrective apparatus sending a command message, e.g. to the controller.

Preferably, the system state detection apparatus is arranged to receive at least two sensor signals; and the prediction module is arranged to predict at least one of the one or more control signals based on the at least two sensor signals.

Preferably the controller state detection apparatus is arranged to receive at least a first control signal and a second control signal; wherein the prediction module is arranged to predict at least an expected first control signal for the first control signal and an expected second control signal for the second control signal; and the anomaly detection module is arranged to detect a possible first anomaly based on the difference between the expected first control signal and the received first control signal and independently to detect a possible second anomaly based on the difference between the expected second control signal and the received second control signal. In such cases separate anomaly alerts may be sent for each control signal. The different control signals may each correspond to a different controller.

Preferably, the controller state detection apparatus is arranged to receive at least a first control signal and a second control signal; the prediction module is arranged to predict at least an expected first control signal for the first control signal and an expected second control signal for the second control signal; and the anomaly detection module is arranged to detect a possible anomaly based on both the difference between the expected first control signal and the received first control signal and the difference between the expected second control signal and the received second control signal. Here, the diagnostic signals may be merged and/or a single alert may be sent.

The diagnostic apparatus and method described herein can be applied to any closed-loop control system controlling physical and even non-physical systems. Some example applications include, but are not limited to, electric motors and water level regulators.

In one embodiment, the actuating module comprises one of: a boiler; a space and/or water heating and/or cooling apparatus; a humidifier; a dehumidifier.

In another embodiment, the actuating module comprises an aircraft actuator, such as an aircraft engine or motor. However the actuating module may comprise other sorts of components or appliances, such as any type of electric motor.

In one embodiment, the control system comprises an HVAC system.

In some embodiments, the control system comprises a chemical control or delivery system.

A further exemplary diagnostic apparatus can be described in relation to a chemical mixing device. A chemical mixing device can comprise a first fluid into which an amount of chemical is introduced (e.g. by a fluid pipe) and where the chemical mixture leaves through an outlet. A control system for this system can be based on a measurable physical quantity (typically the concentration of the chemical) at the outlet of the system. The control system may have continuous control over the flow rate or there may be a series of discrete flow rate settings. The diagnostic, or computational, module is configured to diagnose the state of this control system without specific understanding of how the controller functions - instead it is possible for the computational module to learn about the behaviour of the control system and its surroundings, or the process, incrementally and/or automatically. The described method of inverse control diagnostics modelling evaluates the operation of the system by computing or predicting expected control signals for the system. These control signals are compared to the actual control signals provided to the system. Differences between the actual and expected control signals are used to determine potential anomalies in the system.

In some embodiments the control system comprises an aircraft control system.

In other embodiments the control system comprises a software system or module.

A further exemplary diagnostic apparatus can be described in relation to a software based system, for instance load demand management. A load demand management system can be used to control the number of devices connected to an electricity network and/or the power drawn by these devices. This is advantageous to manage variable loads on the network and/or to shed excess loads. A control system for this system can be based on a measurable physical quantity (typically the measured power flow) at a point or location of the system. The software based control system may have control over a plurality of discrete or continuous loads and provide a control signal which indicates how much power each load can use. The described method of inverse control diagnostics modelling evaluates the operation of the system by computing or predicting expected control signals for the system based on the system outputs (e.g. change in the power usage of the devices). These control signals are compared to the actual control signals provided by the software based system (either control signals to individual loads, or a higher-level control signal to a plurality of loads). Differences between the actual and expected control signals are used to determine potential anomalies in the system.

In some embodiments the actuator is replaced by a software module or component that is controlled by inputs, depending on the outputs of the system/process.

In some cases the actuator itself is not a physical actuator, but may be a software system or module. In other cases the actuator is a physical actuator.

There is also described a control and diagnostic system comprising: a process or system having at least one actuating module and an operation at least a part of which is controlled by the or each actuating module; at least one sensor monitoring the state of the process or system to generate at least one sensor signal; a controller arranged to receive one or more reference signals defining a desired state of the process or system and the or each sensor signal and to generate respective control signals for the or each actuating module to drive the process or system towards the desired state; and a diagnostic apparatus substantially as described above.

There is also described herein a diagnostic method for a closed loop control system, the closed loop control system comprising: a process or system having at least one actuating module and an operation at least a part of which is controlled by the or each actuating module; at least one sensor monitoring the state of the process or system to generate at least one sensor signal; a controller arranged to receive one or more reference signals defining a desired state of the process or system and the or each sensor signal and to generate respective control signals for the or each actuating module to drive the process or system towards the desired state, the diagnostic method comprising: receiving the or each sensor signal; receiving the or each control signal; computing an expected control signal for the or each control signal from the received sensor signals; and detecting a possible anomaly by determining a difference between the expected control signals and the received control signals.

Preferably, the step of computing an expected control signal for the or each control signal from the received sensor signals and/or the step of detecting a possible anomaly comprises: employing a learning algorithm based on the historical behaviour of the system.

Optionally the method further comprises: receiving the one or more reference signals; and predicting the expected control signal for the or each control signal is further based on the received reference signals.

Preferably, the method further comprises: learning expected control signals based on historical behaviour during an initial learning period; operating in a subsequent trained period, wherein during the subsequent trained period the expected control signals are computed based on the expected control signals learnt during the initial learning period.

In some embodiments, detecting a possible anomaly is based on one or more criteria and the one or more criteria varies dependent on the amount of historical behaviour data input into the learning algorithm, preferably such that a threshold for detecting a possible anomaly based on the difference between the expected control signals and the received control signal is lower when more historical behaviour data has been input into the learning algorithm.

Optionally, during the initial learning period, detecting a possible anomaly is based on one or more initial criteria; and during the subsequent trained period, detecting a possible anomaly is based on one or more trained criteria, the one or more trained criteria being different from the one or more initial criteria, preferably wherein the one or more trained criteria have a lower threshold than the one or more initial criteria.

Preferably, the method further comprises: receiving the one or more reference signals; and wherein predicting or computing the expected control signal for the or each control signal is further based on the received reference signals.

Optionally, detecting a possible anomaly is performed by determining a difference between the expected control signals and the received control signals as a function of time.

In some embodiments, the expected control signals are bounded within a control signal range, preferably wherein the control signal range is from 0 to 1. Preferably the received control signals are also bounded within a control signal range, preferably wherein the control signal range is from 0 to 1.

In some examples, the method further comprises: normalising the received control values, preferably by normalising the control values within a range from 0 to 1.

Preferably, the method further comprises: outputting an alert in response to detecting a possible anomaly, for example as a message sent to a user, such as to a smartphone, tablet or computer.

Optionally, the method further comprises: providing one or more corrective actions in response to the detecting an anomaly. For example, the one or more corrective actions may include on or more of: replacing the controller; altering a state or configuration or operating condition of the controller; and discontinuing operation of the controller or control system.

Preferably, detecting a possible anomaly comprises determining that at least one difference between an expected control signal and a corresponding received control signal is greater than a threshold difference.

Optionally, detecting a possible anomaly comprises determining that at least one difference between an expected control signal and a corresponding received control signal persists for more than a threshold time period.

Preferably, detecting a possible anomaly comprises determining that at least one difference between an expected control signal and a corresponding received control signal is non-zero and/or above a threshold difference for more than a threshold proportion of time within a (predetermined) time period.

In some embodiments, the method further comprises: receiving at least two sensor signals; and computing the expected control signal based on the at least two sensor signals. There is also described herein a diagnostic method for a control system, the control system comprising: a process or system having an operation at least a part of which is controlled by a control signal; at least one monitor monitoring the state of the process or system to generate at least one monitor signal; a controller arranged to receive one or more reference signals relating to a desired state of the process or system and/or the or each monitor signal and to generate respective control signals to drive the process or system towards the desired state, the diagnostic method comprising: receiving the or each monitor signal; receiving the or each control signal; computing an expected control signal for the or each control signal from the received monitor signals; and detecting a possible anomaly by determining a difference between the expected control signals and the received control signals.

Preferably the control system is a closed loop control system.

There is also described herein a computer program product or computer readable medium comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods as set out above.

There is also described herein a diagnostic apparatus for a control system, the control system comprising: a process or system having an operation at least a part of which is controlled by a control signal; at least one monitor monitoring the state of the process or system to generate at least one monitor signal; a controller arranged to receive one or more reference signals relating to a desired state of the process or system and/or the or each monitor signal and to generate respective control signals to drive the process or system towards the desired state, the diagnostic apparatus comprising: system state detection apparatus arranged to receive the or each monitor signal; controller state detection apparatus arranged to receive the or each control signal; an estimation module arranged to compute an expected control signal for the or each control signal from the received monitor signals; and an anomaly detection module arranged to detect a possible anomaly by determining a difference between the expected control signals and the received control signals.

Any system feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to system aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

Embodiments will now be described, by way of example only and with reference to the accompanying drawings, in which:

Figure 1 illustrates the main components of an exemplary diagnostics system using inverse control diagnostics, as well as the closed-loop control system it is monitoring;

Figure 2 illustrates an example of observed target or‘set’ temperatures and achieved indoor temperatures (above) of a common space heating controlling a boiler using a binary control signal (below);

Figure 3 illustrates one-step ahead prediction of indoor temperature using SVM (Support Vector Machine) regression;

Figure 4 illustrates control diagnostics by inverse modelling computations of a thermostat control signal, showing only the prediction period;

Figure 5 illustrates a diagnostic system which uses regular control diagnostic modelling, and the closed-loop control system it is monitoring;

Figure 6 illustrates an exemplary diagnostic device for inverse control diagnostics;

Figure 7 illustrates an exemplary diagnostic method for inverse control diagnostics;

Figure 8 illustrates an exemplary method for training a model for use in inverse diagnostic control using machine learning.

This application describes a computational framework for detecting anomalies in control systems. In one exemplary embodiment an online failure alert system for a smart thermostat is provided, however the systems described herein are not limited to Internet- of-Things devices or thermostat controllers.

The diagnostic control by inverse modelling system may apply numerical, data- driven algorithms (such as machine learning, artificial intelligence or more generally applied statistics) to closed-loop control systems with the goal of producing real-time diagnostics around the state of that control system. The raw outputs of this system may be directly interpretable by trained experts or system administrators. Alternatively, the outputs may be processed (e.g. filtered, smoothed, visualised) to make interpretation possible for non-expert users. Automated analysis and/or interpretation is also envisaged.

A computational method for anomaly detection and diagnostic monitoring in control systems is described. The method may work by instantaneous comparison of simulated control inputs with actual control inputs. In some embodiments this is made possible by training a data-driven numerical model in reverse on realised input control signals and observed output sensor signals.

Regular Diagnostics

Numerical models are known in conventional control systems. In one example, a diagnostic model may comprise a numerical model to replicate certain process scenarios in order to calibrate the parameters of the controller. This model use may be an optimisation and usually performed out-of-the-loop. In a second example, a diagnostic model may be used as a simulator of a process (or of an environment) to obtain better control actions. Here the modelling aim is to predict the effect of control choices on the process or environment. This configuration could be in-the-loop and typically involves a carefully tuned‘forward’ simulation of the dynamic system.

Figure 5 shows a modelling strategy 500 that may be used in regular, or conventional, control diagnostic modelling, where:

A is an actuator (or mechanism),

S is a sensor(s), r(t) is a reference signal, e.g. set point,

e(t) is an error term,

u(t) is an input control signal,

y(t) is a system output,

s(t) is a sensor signal,

5(t) is a predicted sensor signal,

d(t) is a diagnostic state signal.

In this configuration a model 550 aims to make a prediction, 5(t), of a sensor signal value, s(t), at time t, the sensor value, s(t), being measured by a sensor 540. The sensor signal value, s(t), is representative of the overall system output, y(t). The input to the model 550 in this case consists of the actual control signal, u(t) that is sent from a controller 510 to an actuator 520 in order to control a process 530. A diagnostic signal, d(t), is computed by considering differences between the observed sensor signal value, s(t), and the predicted sensor signal value, 5(t). The model 550 may, for example, be a simulator based on fundamentals, or a data-driven model, or any hybrid combination. In all cases, the model runs in ‘forward’ mode here, meaning that the output variables emerge as a consequence of the inputs - e.g. as in real life; in other words the‘model stream’ proceeds forward in time.

Note that often there may be additional model inputs, e.g. past/historical sensor observations and reference values. These are not explicitly drawn in Figure 5 for the sake of clarity.

Figure 1 shows a negative feedback and inverse diagnostics modelling control system 100 which may be used, for example, in physical, chemical and electrical engineering applications. A controller unit 110 uses an error signal, e(t), (here defined as the difference between set reference values, r(t), and an observed output) to compute the new control settings or signals, u(t), required to steer the system closer to the set points, r(t). The control signal, u(t), is sent to an actuator 120. Examples of actuators may be heating or cooling devices, such as radiators, air conditioning units, computing systems, medical supply equipment (e.g. drug or oxygen supply devices) etc.

The actuator 120 adjusts its settings (e.g. position, speed, power, etc.) according to the control signal, u(t). This has a certain effect on the environment or process 130. The process or environment 130 produces an output, y(t). The output, y(t), of the environment or process 130 is monitored by one or more sensors 140. The output signal from the sensors 140 is fed back to allow the error signal, e(t) to be calculated.

The system 100 shown in Figure 1 further comprises a computational module 150, which produces real-time predictions. The sensor signal(s) are input into the computational module 150, which uses them to make a predicted control signal, u(t), of the control signal for the most recent time step, u(t). This predicted control signal, u(t), gives an estimate of what the most recent control commands should logically be, given the observed output sensor data.

The predicted control signal, u(t), is then compared to the actual control signal of the same time step, u(t), to derive a difference signal, d(t). The difference signal, d(t), is used to determine system’s diagnostics. For example, a sudden change in the difference signal, d(t), means that the realised controls have become significantly different from the control settings that are expected to occur for current (and/or recent) process/environmental states. This could, for example, be an indication of anomalous behaviour of either the controller unit 110 or the actuator 120. Additionally, or alternatively, this may indicate that the controller 120 has started to operate outside its normal range of conditions.

In contrast to previous systems, such as that shown and described in relation to Figure 5, the proposed system 100 is not aimed at improving the control system directly. The modelling takes place in a secondary loop and does not feed back into the main control loop. The numerical diagnostic model may run in real-time and in reverse compared to forward process simulations. It may use data-driven, empirical modelling to establish mappings between sensor observations and associated control signals, u(t), e.g. the computational module’s inputs are the control system’s outputs and the computational module’s outputs are the control inputs.

Advantageously, it is possible for the computational module to learn about behaviour of the control system and its surroundings, or the process, incrementally and/or automatically. A machine learning algorithm may be used to achieve a prediction of the controls, u(t), based on the available data from the sensors. For example, a record of u(t) and the corresponding sensor output at that time, t, may be stored and used for future predictions of the control signals, u(t’) at time t’. As more historical data corresponding to the control signals u(t) and the sensor output is stored, the algorithm tends to improve incrementally and additionally the time-sensitive system characteristics picked up by the model may gradually become more sophisticated. Hence, over time the module may learn to distinguish more subtle aberrations. After a certain training period it is ready to produce the predictive diagnostic outputs, u(t), while continuing to learn at the same time.

In some cases the training period may be one week, two weeks, or a month. The length of the training period may be dependent on the context and application. It not only depends on time scales present in the control system, but also on the frequency with which 'interesting phenomena' or significant events relevant to the control occur.

The diagnostic signal, d(t), which is output from the computational module 150 could be used directly by experts who know the particular control system 100 and its interaction with the environment from experience. They can interpret the raw diagnostic signal and use it to draw conclusions about potential failures and anomalies. The expert may then decide to take mitigating actions on the user’s behalf, including the decision to re-calibrate the controller’s parameters. The lay user could get access to the predictions through a context-specific interface, such as via an application on a phone or tablet, or via an Internet page. The non-expert user may also have the option to clear the alert, to snooze it or to take other actions, such as to contact a professional.

Method of inverse control diagnostics modelling

Figure 7 shows an exemplary method 700 of control diagnosis by inverse modelling which may be used for a control system or process.

At step 702 one or more sensor signals are received. These sensor signals may be received from sensors which sense outputs for the control system/process. For example in a heating system these may be temperature measurements. Where multiple sensor signals are received these may be from different sensors configured to monitor different conditions/characteristics in the control system (e.g. in an environmental control/HVAC system temperature and humidity may be measured), or the signals may relate to the same characteristic measured for different environments (e.g. in an environmental control/HVAC system temperature of different rooms may be measured).

At step 704 one or more control signals are received. These control signals may relate to control signals sent to actuators in the system by one or more controllers, e.g. one control signal may be received for each actuator. In some cases, a single actuator may be capable of performing more than one function concurrently, in which case a control signal may be received for each function of each actuator. In some embodiments only positive control signals are received, e.g. an“off indication may not be sent. In this case, the method may include inferring that the absence of a control signal corresponds to an“off’ control.

The sensor signals and control signals (and reference values, where appropriate) may be received at predetermined time intervals, e.g. they may be received every five minutes, every minute, 30 seconds, 20 seconds, 10 seconds, 5 seconds, 2 seconds, 1 second, or 500ms or 20ms. Alternatively the signals may be received continuously, e.g. as they are created, such as at the rate control signals are output by the controller and as sensor measurements are measured by the sensor (and as reference values are updated).

At step 706 expected control signal(s) are computed, or predicted, for each of the received control signals. This prediction may be based on the received sensor signal(s). In some examples, a machine learning algorithm based on previous or historical behaviour of the control system (or other similar control systems) may be used to make the prediction, e.g. what control signals were previously used when the same and/or similar sensor signals were received. In some embodiments, multiple sensor signals may read onto a single control signal, e.g. where there are multiple inputs that are factored into what control should be implemented. For example, where the control system is a (de-)humidifier the control may be actuated based on measured humidity values and measured temperatures. In other embodiments, a single sensor signal may affect multiple control signals. For example, where the control system is an HVAC system comprising heating elements and a (de-)humidifier, these may both be controlled based on temperature readings and/or humidity readings.

Where there are multiple control signals, these may be modelled separately, or independently of one another. In some cases they may be modelled in parallel and in other cases they may be modelled in series.

In some embodiments received reference point values (e.g. desired setpoints for the system) are also used to determine the expected control signals.

At step 708 the difference between the expected control signal(s) and the corresponding received actual control signal(s) that have been output by the controller is determined. Where the control signals are binary (e.g. on or off, 1 or 0) the difference may simply be determined as an indication that the expected control signal is not equal to the actual control signal (since the control signals may only take one of two values). Where the control signals can take a number of discrete values, the difference may be determined as the difference between these discrete values.

At step 710, the difference calculated at step 708 is used to determine a potential anomaly in the system. In some embodiments this may be where there are multiple control signals, the anomaly may be identified if only one of the control signals is different from the expected signal.

At step 712 an alert is triggered based on the anomaly. For example, a message may be sent which indicates a suspected anomaly, and in some cases the potential anomaly (or a class or category of the potential anomaly) may be identified. The message may also include a report of recent control and/or sensor data. In some embodiments the alert may be flagged to a user of the system, in other embodiments the anomaly may be flagged to a system administrator or sent to a supplier or manufacturer.

In some embodiments the method 700 of Figure 7 may be performed at a diagnostic apparatus, such as the diagnostic device 600 shown in Figure 6. In other embodiments different steps of the method 700 may be performed at different devices in a distributed system, e.g. on one or more remote cloud servers and/or local devices (e.g. devices which are located in proximity to the control system, e.g. in the same building). Figure 8 shows a method 800 for training an inverse control diagnostic system. The method 800 may be performed for a certain (predetermined) training period prior to the method 700 of Figure 7 beginning. In some embodiments the training method 800 may continue to run in parallel with method 700 to refine further the model.

The training method 800 starts at step 802 where sensor signals are received, similar to step 702. At this stage, there is no historical data for the control system and thus no learnt model. In some embodiments a standard or template model for the system may be provided.

At step 804 control signals are received, e.g. from the controller, similar to step

704.

In some embodiments, reference (or desired setpoint) signals may also be received at this stage.

At step 806 a control model is built based on the received sensor signals and control signals (and optionally the reference signals). This control model may then be used to predict the expected control values in step 706 of Figure 7.

At step 808 additional sensor signals are received. At step 810 additional control signals are received. In some embodiments additional reference signals are also received here.

At step 812 the model that was determined at step 806 is refined based on the additional sensor and control (and optionally, reference) signals.

At step 814 the model from step 806 is output and/or stored. For example it may be stored in the prediction module. Thus the updated model may then be used to predict the control values at step 706 of Figure 7.

The method 800 then returns to step 808 to receive additional sensor signals, and the model may be refined or adjusted again based on the newly received signals. Diagnostic Apparatus

Figure 6 shows a hardware architecture of an exemplary diagnostic device 600 which may be used for inverse diagnostic modelling for control systems.

The diagnostic device 600 includes a processor 630 together with volatile / random access memory 660 for storing temporary data and software code being executed. Random access memory 660 may be used to store continuously the received sensor and control signals and/or the predicted expected control signals. Persistent storage 670 may store control information 680, for example standard/template and/or determined/refined control models. Persistent storage 670 may include other software and data, such as an operating system, device drivers, software configuration data, historical sensor and control data, and the like.

Communication with components in the control system such as the sensor(s) and controller(s) occurs via a wireless network interface 605 and wireless transceiver 610. In alternative embodiments, a wired interface and wired connections may be used. The wireless interface 605 and transceiver 610 may also be used to communicate alerts, e.g. alert messages and information, e.g. to users of the system and/or system administrators or engineers or manufacturers.

The received sensor and control information is passed to the processor 630, which stores the information in memory 660 and/or persistent storage 670 for use in diagnosis.

A controller state detection module 625 is provided for receiving the control signals. A system state detection module 620 is provided for receiving the sensor signals. An estimation module 640 is provided for computing expected control signals and an anomaly detection module 650 is provided for identifying potential anomalies.

The device components are interconnected by a data bus (this may in practice consist of several distinct buses such as a memory bus and I/O bus). While a specific architecture is shown, any appropriate hardware/software architecture may be employed. For example, external communication may be via a wired network connection.

Example: thermostat

An exemplary diagnostic apparatus will now be described in relation to a thermostat with binary boiler control. A domestic thermostat for space heating is usually a control system based on a single, measurable physical quantity (typically the indoor temperature) operated with binary controls (e.g. having only two possible states:“on” or “off’), and having pre-set, but adjustable set points. Unrelated to how the controller functions (e.g. whether it is with a fixed set of parameters or with added‘intelligence’) the diagnostic, or computational, module is configured to diagnose the state of this control system. The evaluations of the diagnostic/computational module are in this case based on the same temperature sensor data that is used by the thermostat itself and the commands used to control the boiler (the binary on/off flags of the controlling device inside the boiler). The diagnostic/computational modelling task in this case consists of a time-windowed binary classification, for which suitable algorithms include, among others, Support Vector Machines, Neural Networks and several Bayesian approaches. The advantage of the diagnostic/computational approach here is that it can achieve real-time diagnostics without knowing specific details about the installed equipment (boiler power, boiler type etc.) and without specific information about the environment (house size, insulation, outside temperature etc.).

Advantages of diaqnostic/computational system

What follows is a short discussion on advantages of the inverse way of control system diagnostics as proposed in the diagnostic/computational framework over conventional diagnostics. The case study of a diagnostic/computational system applied to a heating system forms one example.

1. Interpretation and use of model output is easier

Processing and interpreting the model output of a conventional, forward model prediction of a sensor variable is much more ambiguous than using the output from the inverse diagnostic/computational module because such forward model prediction may lack a standard format. The inverse diagnostic/computational model output is in many cases bounded to a normalised interval, for example the interval [0,1] and therefore defining post-processing actions tends to be simpler, regardless of the application or numbers of users.

2. Model choice, model definition, model selection, model training

There may be difficulties with applying a numerical model in‘forward mode’. A model application used in the conventional way is generally required to be a trade-off between prediction accuracy and how well it represents the internal features of the control system. This means that the model type needs to be chosen carefully and is commonly hand-crafted to fit each specific situation. This step usually involves gathering information about the control system, e.g. looking into how the control mechanism interacts with the environment and possibly how outside factors affect the sensor output variable. This system knowledge can come from fundamental mathematical theoretical descriptions or from additional data sources. In the example of a heating control system for a house it could be beneficial to use the heat dynamics equations and include observed outside temperatures in the prediction of the future indoor temperatures, for example.

In contrast, the reverse modelling set-up of the presently described diagnostic/computational system does not require much prior system knowledge. By predicting the control signals it may be possible to use a black-box, data-driven algorithm. When the model undergoes data-driven training, it may automatically reverse engineer the controls from the observed outputs, e.g. it learns a suitable mapping without needing information about the inner workings of the control system and its process first, which would often require a human to scrutinise and set up. Model selection is generally simpler than in a forward mode prediction system because there exists a range of classification and regression algorithms available in the field of machine learning that can be used without which may not require domain-specific adjustments. Advanced learning aspects common to machine learning can be applied to increase accuracy.

When the control signal that is to be predicted is discrete, the diagnostic/computational model may use a classification algorithm. If the controller is binary, then this may be a binary classification (as in the thermostat example above); if it is discrete but not binary, it may be a multi-class classification. If the control signal is continuous, then the diagnostic/computational model may include, or consist of, a regression algorithm. The question of what type of classification or regression algorithm is most suitable may depend on the complexity of the controller and/or on the dynamics of the system as reflected by its output signal.

3. Nature of target signal

The control variable may be an easier‘target variable’ to predict than a domain- specific system output. Control signals are typically one-dimensional, often discrete, and bounded and usually linear in case they are continuous. In order to provide acceptable results, system output variables that are predicted in a forward configuration ought to represent the system and its environment (so that it is possible to gauge how closely the target values were reached). Therefore these output signals may inherit the complexity of the system and its environment, with all the associated degrees of freedom. The control signal on the other hand, by its very nature, is less variable and since it is driving the actuator it generally would not assume any unexpected values.

The inverse diagnostic/computational module, by modelling from the system output variable onto the control variable, essentially projects a mapping that‘funnels’ the complexity of the system output variable to the generally much simpler control variable that acts as the model’s target variable.

Finally, an output variable sensor is generally more likely to contain noise or suffer from outages than a control signal. The control signal comes from a controller that is central to the control system and thus generally should be designed so that it is not noisy or erratic since the proper functioning of the control system depends on it.

4. Models are easier to train in the inverse diagnostic/computational configuration

The presently described computational reverse control diagnostics model is generally easier to train than a forward simulation model. This is understood to be because achieving acceptable training results for a model with a continuous target variable with unknown bounds requires variation of the training over a wider range than for a model with a bounded (and often discrete) target variable. Thus calibrating a forward model with more complex outputs requires longer and more processing than training a reverse diagnostic/computational model as described herein. Thus with the same (amount of) data, the present diagnostic/computational module may be able to achieve a higher accuracy than most forward simulation models.

Example: heating system

Figure 2 is a chart showing the observed inside temperature of an exemplary premises over a 48 hour period. The example premises is a household thermostat equipped with basic functionality that measures the indoor temperature, generating a sensor signal that is representative of the state of the process. The upper plot 210 shows the observed indoor temperature over a period of 48 hours. The reference set points 220 in this context consist of target temperatures, which are often pre-selected and stored on the device as a daily or weekly schedule.

The user can manually change the target temperature 220 at any time, thus overriding the pre-set schedule. Whenever the target temperature 220 is set above the indoor temperature 210 (or the indoor temperature 210 drops below the target temperature 220), a binary control flag 230 switches to the value 1 , the ON’ state. This triggers a heating element in the boiler which subsequently warms up the radiators in the house and thereby causes the indoor temperature 210 to rise. Naturally, in the OFF’ state (boiler flag=0), the house cools down until the temperature either reaches an equilibrium temperature related the outdoors temperature, or until a new heating cycle is triggered. Note that this is not a complete description of a thermostat-boiler control system. There exist many subtleties in how boilers operate and some thermostats have more advanced logic in their controller - it is not necessary to consider these aspects here.

Comparing the upper and lower plots of Figure 2, it is seen that the control flag 230 matches the expected heating states (ON/OFF) implied by the temperature difference between the target temperature 220 and indoor temperature 210. The intended working of this space heating system as described above seems rather straightforward at first glance, as the indoor temperatures in most heating events rise quickly after the control flag came on. However, there is one exception: at 16:00h on November 25th the target 220 changes from 12°C to 20°C thus triggering the heating control 230 to come on. However, this does not lead to an increased indoor temperature 210 - it seems to continue cooling as if the control never switched on. This can be considered a departure from normal operation of this control system and therefore an anomaly.

Forward simulation model

We now consider two ways to apply numerical computer model simulations that would help spot this anomaly in real-time. In a conventional setting, a model could be trained to produce forecasts of the indoor temperature and compare this with actual, achieved indoor temperature (which would be measured by the sensor).

Figure 3 shows an exemplary chart of measured indoor temperature 310, along with a temperature prediction 320. Such a configuration can be summarised in discrete- time by:

(equation 1 )

Where:

T _t denotes the observed indoor temperature at time t,

T _t is the predicted indoor temperature by the numerical model at time t,

C _t is the actual control signal at time t, and

D _t is the diagnostic signal comparing the actual temperature with predicted (forecasted) temperature at time t.

f and g are functions determined as part of model training.

The inputs of this forward time series prediction model coincide with the inputs of the control system itself since the control signal is effectively a function of the indoor and target temperatures.

There are many types of numerical models to choose from for the task of defining function f in the above equation. Here, the Support Vector Machine algorithm with a Radial Basis Function kernel (SVM-RBF) was used to perform regression to make a one-step-ahead prediction based on a sliding window consisting of 15 data points (e.g. k=15 in equation 1 ). The sample frequency of the temperature data is 2 minutes. This is a data-driven approach that makes no assumptions about inner workings of the underlying control system - in particular it is a non-linear model with flexible granularity, as expressed in the hyperparameter gamma of SVM-RBF which was tuned on the same training set.

Figure 3 does not show a prediction for the initial period because in this example the first 1.5 days are used as a training period for the model (to the left of cut-off 330). The actual prediction (‘testing’) shown in Figure 3 is for the remaining time (to the right of cut-off 330); starting at 10:00h on 25 November. The plotted prediction result indicates that in general the one-step-ahead predictions are accurate as the temperature prediction 320 matches the measured indoor temperature 310, as can generally be expected for a low-dimensional prediction of moderate complexity. There is a clear bump in the predicted temperature 320, starting at 16:00h on November 25th, where it diverges from the measured indoor temperature 310. This departure from an otherwise accurate prediction could be exploited as an indicator for anomalies. Indeed, if we define the function g in equation (1 ) simply as (equation 2)

where AT _t is T _t - T _t then the resulting diagnostic signal D would be close to zero most of the time and reveal the anomaly as a temporary bump.

One could argue that the described time series forecast is not as accurate as it could be, perhaps because it does not sufficiently utilise the latest temperature observations to update the prediction (as for instance a Kalman filter would), which in this case could causes the discussed discrepancy between prediction and observation. One might think that we would be even better off using an auto-regressive model of the form T _{t+ i} = f(T _t, T _t -i _, T _t,..„ T _t.k ). Indeed, a trivial‘naive’ temperature forecast f _{t+ i} = T _t, would clearly beat the forecast from 17h to 18h on November 25th as shown in Figure 3.

However, the control signal should be incorporated in the feature vectors in order to create a link between input and output of the control system being monitored. The goal is not just to increase the forecasting precision of the observed, dependent quantity, but also to somehow capture the‘cause-and-effect’ process of how that output came about as a result of the system under scrutiny and its inputs.

Reverse diagnostic model using inverse modelling

Now we consider the reverse or backward modelling strategy as used in the system proposed herein. The modelling in this case consists of predicting the control signal instead of the indoor temperature. In fact, the control signal and the indoor temperature swap places, expressed in equations as follows: (Equation 3)

Figure 4 shows the result of applying control diagnostics by inverse modelling to the anomaly detection problem at hand. Figure 4 shows computations of a thermostat control signal for only the prediction period of Figure 3. The upper part of Figure 4 shows the one-step-ahead predictions of the control signal, the actual control signal at those times, plus the predicted probabilities of the control value. In the lower part of Figure 4, the diagnostic signal is plotted along with a derived alert signal. A simple threshold is able to reveal critical system behaviour around 17:00h on 25-Nov.

The plots zoom in on the final 12 hours of the plot of Figure 3 (to the right of line 330), in which predictions are made. In the upper part of Figure 4, the actually achieved control, plot 410 is shown and on top of that the one-step-ahead control predictions c _t are plotted as line 420.

The control predictions shown in Figure 4 are made using a Support Vector

Machine binary classification algorithm with a Radial Basis Function kernel trained on the same time window as in Figure 3, and again with a sliding window of 15 subsequent observations. The upper plot of Figure 4 shows that there are clear differences between the actual and predicted control signals. Firstly, the anomalous heating event between

16:00h and 17:00h on 25-Nov is predicted to have no control activity at all. According to the model, the observed temperature pattern around this time is what indicative of a regular cooling situation that would occur if the heating system was switched off. That is, despite the actual controls 410 being ON during this time, there is no discernible impact in terms temperature rise (according to the model).

There are a few other, smaller time periods around the heating event starting at 20:00h on 25-Nov that show discrepancies between actual control 410 and predicted control 420. These seem to be partly related to thermal lags between the system’s heating controls switching on and associated temperature rise becoming observable. These are known and typically non-critical phenomena. Lastly, the top plot in Figure 3 also shows the prediction probability 430 of the classifier, a by-product of the classification indicative of the‘confidence’ of the algorithm of its classified outputs.

Regarding the lower plot of Figure 4, consider first the following two choices for error function g: i(&C _t ) ~ maxCAC _t , 9) (Equation 4)

Where:

AQ IS Q - C _t .

The diagnostic signal 440 in the lower part of Figure 4 is defined as g The shaded patches in the plot 440 indicate the moments when this signal equals 1 , it is zero otherwise. The diagnostic signal 440 is subsequently used to derive a secondary alert signal 450, defined according to g ₂ , which looks like a“saw tooth” signal in the lower part of Figure 4. The idea behind this alert signal is to illustrate how easily the difference between the actual and predicted controls can be utilised as a real-time anomaly indicator. The definition of the alert signal (i.e. function g ₂ ) means that non-zero differences between actual and predicted controls are accumulated as long as the ‘difference event’ marked by non-zero AC _t lasts. As soon as the actual and predicted controls are identical again (or at least the identical to within a comparison threshold), such an event is over and the summation alert signal 450 is reset to zero. Note that the diagnostic signal function g ₁ does not use the absolute difference in this particular application as it does not register situations where the actual control is off while it is predicted that the controls should be on - this is considered to be a benign anomaly without consequences (although in other contexts this would not necessarily be the case).

In the current example case the alert signal 450 can be used in a straightforward manner to distinguish between short, non-critical events and prolonged anomalous events worth sending alerts about or looking further into. This is achieved by applying a simple, constant alert threshold 460 to the alert signal 450. Once the alert signal 450 passes the threshold 460, a critical period 470 is identified.

Difference between forward and backward diagnostics: Post-processing of diagnostic signal

The above example illustrates the working of the control diagnostics by inverse modelling configurations and in doing so highlights one of the advantages of the backward (reverse/inverse) model configuration over forward simulations aimed at control diagnostics: its output is more readily interpreted and post-processed for anomaly detection.

This can be illustrated by comparing the ‘error functions’ g that define the diagnostic signal. In the forward modelling case, the input domain of g is determined by the range characteristics of the observed variable. If this happens to be a continuous variable with a wildly varying range, then the function g and/or subsequent derived functions need to somehow deal with this variation in order to get an easily interpretable final alert signal. In the reverse modelling diagnostic control case, however, the function g works on a control difference signal, with the same input domain set as the original control signal itself.

Error function g of the inverse modelling control diagnostic system typically works on a discrete set of values, in the above example it maps from {0,1} to {0,1}. If the controller uses continuous values instead, this may still be a bounded set in the vast majority of physical control applications (and associated actuator). It is relatively simple to project a given bounded range of values produced by a continuous controller to the interval [0,1] without loss of generality. This would essentially give a diagnostic signal very similar in appearance as the prediction probability signal plotted in the upper plot of Figure 4. This signal type is similarly easy to interpret and process as the binary 0/1 signal.

One advantage of having a simple diagnostic output signal in a standard format is that it may make it easier to define unambiguously a threshold that should discriminate between anomalies and normal events. Forward modelling of an observed system output variable is likely to lead to an a priori unknown range of values. In the example of a heating control system, the temperature variations are of course not unbounded, but the point is that the bounds are not known for specific cases. For one house the highest achievable temperature could be 24°C while for another it could be 19°C. This variance is inevitably reflected in the diagnostic error signal and may require non-trivial design choices to make it work in all cases. Again, the reverse control diagnostics by inverse modelling approach does not suffer from this ambiguity; the diagnostic signal has a standard form thus allowing much easier thresholding and therefore (automated) decision-making will be generally more straightforward and possibly more reliable as a result.

The above embodiments and examples are to be understood as illustrative examples. Further embodiments, aspects or examples are envisaged. It is to be understood that any feature described in relation to any one embodiment, aspect or example may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, aspects or examples, or any combination of any other of the embodiments, aspects or examples. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.