Electrical device failure forecasting

Abstract

A method and apparatus (110) for forecasting failure for electrical devices in a circuit is provided. Energy meter data is acquired (231) from an energy meter (100), comprising load data corresponding to devices in a circuit. This is disaggregated into device specific load data. Events are detected in the disaggregated load data. Forecast changes in values of operational parameters for the devices in the circuit due to a detected event are determined (241) with a temporal fusion transformer model. Potential future events are determined (242) based on the forecast changes in values of operational parameters for the devices, and a notification is output (243) indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

Description

[0001] Electrical Device Failure Forecasting

[0002] Field

[0003] Aspects of the present disclosure relate to electrical anomaly detection, the identification of the origin of electrical anomalies, and forecasting of failure of electrical devices.

[0004] Background

[0005] Voltage fluctuations or electrical noise can be a potential hazard and dangerous in certain situations. Strong fluctuations can disrupt the normal operation of electrical devices, and can cause electrical shocks or fires, glitches, data corruption, disruption the proper functioning of critical systems (e.g., medical equipment or industrial control systems), interference with aircraft avionics or vehicle control systems (potentially leading to safety issues or accidents), and even permanent damage to sensitive components (e.g., microchips and integrated circuits).

[0006] Voltage fluctuations or electrical noise can occur from various scenarios, such as electromagnetic interference (EMI), voltage surges, arc faults, and brownouts. EMI is one of the biggest challenges of any electronic device. Large electrical devices with electric motors, such as refrigerators or vacuum cleaners, can produce EMI when they operate. This interference can introduce electrical noise into the power lines, which may affect the proper functioning of nearby microprocessors or sensitive electronic equipment. This can affect the performance of the device due to the interference, and cause dangerous situations (Mathur, P., Raman, S. Electromagnetic Interference (EMI): Measurement and Reduction Techniques. J. Electron. Mater. 49, 2975-2998, 2020).

[0007] As the number of electronic devices increases, there is an increase in electromagnetic radiation in which these systems operate which has a potential to interfere with the normal operation of electronic communication links and systems (M. Kaur, S. Kakar and D. Mandal, "Electromagnetic interference," 3rd International Conference on Electronics Computer Technology, Kanyakumari, India, 201 1 , pp. 1-5).

[0008] Hu, C. et al. (Hu, C., Qu, N. & Zhang, S. Series arc fault detection based on continuous wavelet transform and DRSN-CWwith limited source data. Sci Rep 12, 12809, 2022) describes series arc fault detection based on continuous wavelet transform and deep residual shrinkage network with the channel-wise threshold (DRSN-CW).

[0009] Li, B. and Jia, S. (Li, B., Jia, S. Research on diagnosis method of series arc fault of three-phase load based on SSA-ELM. Sci Rep 12, 592, 2022) describes a diagnosis method of series arc fault of three-phase load, based extreme learning machine (ELM) optimized by sparrow search algorithm (SSA). In the case of brownouts, some appliances with high power requirements can cause voltage drops or brownouts in electrical system when they draw a significant amount of power.

[0010] A rapid rise in power consumption, by both industrial and residential buildings, as compared to power generation is being observed (Anshul Agarwal, Kedar Khandeparkar. Distributing power limits: Mitigating blackout through brownout, Sustainable Energy, Grids and Networks, Volume 26,2021 ,100451 , ISSN 2352-4677). These voltage drops can dramatically affect the stable operation of electronic devices, which can potentially lead to data corruption or damage.

[0011] In some cases an uninterruptible power supply (UPS) can be used for individual devices, but often electrical devices are not protected against these anomalies.

[0012] Aspects herein overcome the aforementioned challenges, amongst others.

[0013] Summary

[0014] In a first exemplary aspect, there is provided a method of forecasting failure for electrical devices in a circuit, the method comprising: in monitoring phase: acquiring energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detecting one or more events in the disaggregated load data by interpretable machine learning; in the forecasting phase: determining, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the circuit due to an event of the one or more detected events; determining potential future events for each device based on the forecast changes in values of operational parameters for the devices; and outputting a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

[0015] Optionally, the method further comprises: in a feedback phase: determining, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determining whether there is an agreement between the sentiment in the feedback and the forecast potential future events; when there is agreement between the sentiment and the forecast potential future events, retraining models used in the monitoring phase and the forecasting phase based upon the agreement.

[0016] Optionally, in the feedback phase the method further comprises: when there is a disagreement between the sentiment and the forecast potential future events, determining a cause of the disagreement, and retraining models used in the monitoring phase and the forecasting phase based upon the disagreement.

[0017] Optionally, the method further comprises determining whether each detected event exceeds a predetermined threshold for the respective device, and performing the forecasting phase for an event of the one or more detected events when the event does not exceed the predetermined threshold for the respective device.

[0018] Optionally, the method further comprises: determining a cause of the event exceeding the predetermined threshold for the device when a detected event exceeds the predetermined threshold for the respective device.

[0019] Optionally, in the feedback phase the method further comprises: determining, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determining whether there is agreement between sentiment in the feedback and the determined cause of the event exceeding the predetermined threshold for the device; when there is an agreement between the sentiment and the cause of the event exceeding the predetermined threshold for the device, retraining models used in monitoring phase and the forecasting phase based upon the agreement; and when there is a disagreement between the sentiment and the cause of the event exceeding the predetermined threshold for the device, determining a cause of the disagreement, and retraining models used in monitoring phase and the forecasting phase based upon the disagreement.

[0020] Optionally, a detected event exceeding the predetermined threshold for the respective device is indicative of a breakdown of the device.

[0021] Optionally, the energy meter is a smart electricity meter and the circuit comprises devices connected to the smart electricity meter; or the energy meter is connected to a vehicle, and the circuit comprises electrical devices of and / or connected to the vehicle.

[0022] Optionally, the method further comprises: in a training phase: acquiring a plurality of historic energy meter datasets, wherein the historic energy meter datasets are from a plurality of energy meters, and each historic energy meter dataset comprises historic load data that is disaggregated into to device specific load data for a plurality of devices in a circuit connected to a respective energy meter of the plurality of energy meters; for each historic energy meter dataset, applying multivariate change event analysis to the disaggregated historic load data to determine relationships between historic events between the devices in the disaggregated historic load data; for each historic energy meter dataset, determining historic event parameters and historic event patterns based upon the determined relationships between historic events between the devices in the circuit; and storing the historic event parameters and historic event patterns.

[0023] Optionally, in the monitoring phase, the method further comprises comparing the detected events to the historic event parameters and the historic event patterns to match the detected events to the historic events, and when a detected event matches a historic event, marking the detected event as a known detected event; wherein in the forecasting phase, known detected events are used to determine the potential future events based upon the determined relationships between historic events between the devices in the training phase.

[0024] Optionally, the historic energy meter dataset further comprises historic ambient temperature and / or humidity data proximal to the energy meter as a function of time; the energy meter data further comprises ambient temperature and / or humidity data proximal to the energy meter as a function of time; and the training phase further comprises determining relationships between historic events and levels / changes of temperature and / or humidity, based on the historic ambient temperature and / or humidity data; the monitoring phase further comprises comparing the detected events and ambient temperature and / or humidity data to the determined relationships between historic events and levels / changes of temperature and / or humidity, and when there is a match between a detected event and ambient temperature and / or humidity data with the determined relationships between historic events and levels / changes of temperature and / or humidity, marking the detected event as a known detected event due a to a level / change of temperature and / or humidity; and in the forecasting phase known detected events due a to a level / change of temperature and / or humidity are used to determine the potential future events.

[0025] Optionally, an event comprises one or more of a change in voltage, current and resistance of a device in the circuit.

[0026] Optionally, the notification indicating a potential future breakdown of a device is output when there is a change in probability of the potential future breakdown occurring and / or a change in expected time until the potential future breakdown is forecast to occur.

[0027] In a second exemplary aspect, there is provided an apparatus configured to forecast failure for electrical devices in a circuit, the apparatus comprising: a monitoring module configured to perform a monitoring phase, wherein the monitoring module is configured to: acquire, with a data acquisition module, energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detect one or more events in the disaggregated load data by interpretable machine learning; a forecasting module configured to perform a forecasting phase, wherein the forecasting module is configured to: determine, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the circuit due to an event of the one or more detected events; determine potential future events for each device based on the forecast changes in values of operational parameters for the devices; and output, with an output module, a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

[0028] Optionally, the apparatus further comprises: a feedback module configured to perform a feedback phase, wherein the feedback module is configured to: determine, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determine whether there is an agreement between the sentiment in the feedback and the forecast potential future events; when there is agreement between the sentiment and the forecast potential future events, retrain models used in the monitoring phase and the forecasting phase based upon the agreement.

[0029] Optionally, the apparatus further comprises: a training module configured to perform a training phase, wherein the training module is configured to: acquire a plurality of historic energy meter datasets, wherein the historic energy meter datasets are from a plurality of energy meters, and each historic energy meter dataset comprises historic load data that is disaggregated into to device specific load data for a plurality of devices in a circuit connected to a respective energy meter of the plurality of energy meters; for each historic energy meter dataset, apply multivariate change event analysis to the disaggregated historic load data to determine relationships between historic events between the devices in the disaggregated historic load data; for each historic energy meter dataset, determine historic event parameters and historic event patterns based upon the determined relationships between historic events between the devices in the circuit; and store the historic event parameters and historic event patterns.

[0030] Optionally, the second exemplary aspect can include the optional features of the first exemplary aspect.

[0031] In a third exemplary aspect, there is provided a means for forecasting failure for electrical devices in a circuit, the means for forecasting failure for electrical devices in a circuit comprising: a means for monitoring configured to perform a monitoring phase, wherein the means for monitoring is configured to: acquire, with a data acquisition module, energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detect one or more events in the disaggregated load data by interpretable machine learning; a means for forecasting configured to perform a forecasting phase, wherein the means for forecasting is configured to: determine, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the circuit due to an event of the one or more detected events; determine potential future events for each device based on the forecast changes in values of operational parameters for the devices; and output, with an output module, a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

[0032] Optionally, the means for forecasting failure for electrical devices in a circuit further comprises: a means for feedback processing configured to perform a feedback phase, wherein the means for feedback processing is configured to: determine, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determine whether there is an agreement between the sentiment in the feedback and the forecast potential future events; when there is agreement between the sentiment and the forecast potential future events, retrain models used in the monitoring phase and the forecasting phase based upon the agreement.

[0033] Optionally, the means for forecasting failure for electrical devices in a circuit further comprises: a means for training configured to perform a training phase, wherein the means for training is configured to: acquire a plurality of historic energy meter datasets, wherein the historic energy meter datasets are from a plurality of energy meters, and each historic energy meter dataset comprises historic load data that is disaggregated into to device specific load data for a plurality of devices in a circuit connected to a respective energy meter of the plurality of energy meters; for each historic energy meter dataset, apply multivariate change event analysis to the disaggregated historic load data to determine relationships between historic events between the devices in the disaggregated historic load data; for each historic energy meter dataset, determine historic event parameters and historic event patterns based upon the determined relationships between historic events between the devices in the circuit; and store the historic event parameters and historic event patterns.

[0034] Optionally, the third exemplary aspect can include the optional features of the first exemplary aspect.

[0035] In a fourth exemplary aspect, there is provided a computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps: in monitoring phase: acquiring energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detecting one or more events in the disaggregated load data by interpretable machine learning; in the forecasting phase: determining, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the due to an event of the one or more detected events; determining potential future events for each device based on the forecast changes in values of operational parameters for the devices; and outputting a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

[0036] Optionally, the steps further comprise: in a feedback phase: determining, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determining whether there is an agreement between the sentiment in the feedback and the forecast potential future events; when there is agreement between the sentiment and the forecast potential future events, retraining models used in the monitoring phase and the forecasting phase based upon the agreement.

[0037] Optionally, the steps further comprise: in a training phase: acquiring a plurality of historic energy meter datasets, wherein the historic energy meter datasets are from a plurality of energy meters, and each historic energy meter dataset comprises historic load data that is disaggregated into to device specific load data for a plurality of devices in a circuit connected to a respective energy meter of the plurality of energy meters; for each historic energy meter dataset, applying multivariate change event analysis to the disaggregated historic load data to determine relationships between historic events between the devices in the disaggregated historic load data; for each historic energy meter dataset, determining historic event parameters and historic event patterns based upon the determined relationships between historic events between the devices in the circuit; and storing the historic event parameters and historic event patterns.

[0038] Optionally, the fourth exemplary aspect can include the optional features of the first exemplary aspect.

[0039] Brief Description of Drawings

[0040] Examples of the disclosure are now described with reference to the drawings, in which:

[0041] Figure 1 is a block diagram of a system comprising an apparatus for electrical device failure forecasting;

[0042] Figures 2a and 2b are a flow chart of a method of electrical device failure forecasting; and

[0043] Figure 3 is a high-level block diagram of an apparatus suitable for implementing various aspects of the disclosure.

[0044] Detailed Description

[0045] The present disclosure provides an apparatus and method which investigates electrical anomalies in real-time, or near-real-time, and ahead of time, and predicts the potential risk of failure in the future.

[0046] The apparatus and method track the operational patterns and thresholds of electrical devices connected to an energy meter. This can effectively discover anomalies and correspondingly address the underlying issues.

[0047] In some instances, the faulty behaviour of large electrical devices can affect nearby sensitive microchips and integrated circuits. The apparatus and method can discover these anomalies and meanwhile predict probable future faults that may happen. In most cases, small anomalies can go unnoticed, but the accumulation of these defects over time can be the result of a serious problem. The apparatus and method described herein can provide for the discovery of otherwise unnoticed fluctuations and prevent valuable devices from failure. The apparatus and method are also beneficial in improving hardware device algorithms (e.g., arc fault detection devices or similar) and can contribute to smart meters internal logic. Machine interpretability can be used to improve the thresholds and find new patterns which can be applied or used to improve the existing hardware capabilities.

[0048] A feedback loop can also be used for continuous improvement in algorithms, threshold, patternfinding and adding accurately labelled real time data into a database after user feedback. This can solve the need of manual intervention for labelling data in the long term.

[0049] Figure 1 is a block diagram of a system comprising an apparatus 110 for electrical device failure forecasting that can bring about the aforementioned advantages.

[0050] The apparatus 110 can be communicatively connected to an energy meter 100 by a network or communication means, either in a wired or wireless manner.

[0051] For example, the energy meter can be an electricity meter, and more specifically a smart meter such as an AMI (advanced metering infrastructure) meter. In such cases, the apparatus 1 10 can be communicatively connected to the energy meter 100 through a network such as a smart meter network. The apparatus 110 can receive energy meter data from an energy meter through such a connection.

[0052] In another example, the energy meter can be a device integrated into a vehicle, such as an aeroplane, and can record energy usage data of the electrical circuits in the vehicle.

[0053] In some examples, the apparatus may be a device such as a computer or a server, or any other type of device suited for executing the methodology described herein.

[0054] The apparatus can comprise one or more modules and datastores adapted to perform the methodology described herein. These can include an energy meter data acquisition module 111 that can communicate with the energy meter to acquire energy meter data, a training module 112, a historic event datastore 113, a monitoring module 114, an event datastore 115, a forecasting module 116, a feedback module 117, and an output module 118. Whilst described as distinct modules, these modules can be embodied as a single module or groups of modules. For example, the module(s) can be realised as one or more processors executing instructions stored in computer storage. Likewise, whilst described as separate datastores, these datastores can be embodied as a single datastore, groups of datastores orthe like, for example as electronic storage integrated into or connected to the apparatus 110. The operation of these modules and datastores is discussed in more detail with reference to Figures 2a and 2b.

[0055] The system can also comprise an output means 120. The output means 1 15 can, for example, be a display or printer, or a communication channel (such as a network path or telecommunications connection) to another device. The output means can be configured to output alerts, notifications, or the like generated by the apparatus performing the methodology described herein.

[0056] Figures 2a and 2b are a flow chart of a method of electrical device failure forecasting that can be performed by the apparatus 1 10.

[0057] The process can involve a training phase 220 in which the apparatus learns the relationships between electrical events of different devices in a circuit using historic data sourced from a plurality of energy meters. Then, a monitoring phase 230 can be performed in which the apparatus monitors a circuit, using data from an energy meter, for electrical events. A forecasting phase 240 is performed in which the apparatus forecasts the future impact of detected events on the devices in the circuit. The historic data from the plurality of energy meters is used in detecting the events and forecasting the future events through a determination of parameters of the events and relationships between different events for different devices in the circuit. A feedback phase 250a, 250b is performed in which user feedback is compared to the forecast events to improve ground truths in the training of the models used by the apparatus.

[0058] In the present context, an event can be considered as an electrical event at a device, for example a change (or spike) in voltage, current and / or resistance of a device. Events can be caused by, for example, EMI, voltage surges, arc faults, and brownouts. An event at one device in a circuit can be caused by an event at a different device in the same circuit.

[0059] At step 220, the process can begin with the training phase being performed. The steps for the training phase can be performed, for example, by the training module 112 of the apparatus 110.

[0060] At sub-step 221 , a plurality of historic energy meter datasets can be acquired. The historic energy meter datasets can be from a plurality of energy meters, and each historic energy meter dataset can comprise historic load data corresponding to devices in a circuit connected to a respective energy meter of the plurality of energy meters.

[0061] The historic energy meter datasets can be acquired, for example, by the energy meter data acquisition module 111 of the apparatus 110. These may be acquired directly from energy meters, or from a datastore storing historic energy meter data.

[0062] In other words, the historic energy meter datasets comprise datasets from a plurality of energy meters, and each of these energy meters can be connected to a circuit having a plurality of devices (e.g. electrical appliances etc.) in it. The historic load data from each energy meter corresponds to these devices. Each energy meter does not need to be connected to an identical circuit; each circuit can have different devices in it. For example, a first circuit may include an air conditioning unit, lighting, a television, and a computer (amongst others); a second circuit may include an oven, an electric vehicle charger, and a refrigerator (amongst others). When there are a large number of historic datasets (i.e., datasets from a large number of energy meters), there can be a large number of different devices across all the circuits connected to these energy meters; some circuits may have some of the same types of devices in as others. For example, the energy meter datasets may be sourced from 10,000 different energy meters.

[0063] These historic energy meter datasets can be recorded over long periods of time; for example, 5 to 10 years.

[0064] In this way, strong statistics can be achieved for the training.

[0065] The historic energy meter datasets can also comprise historic environmental data proximal to the energy meter that coincides temporally with the historic load data, such as temperature and ambient humidity of the room in which the energy meter is located, or inside a box in which the energy meter is located. This can be measured with environmental sensor(s), such as a temperature sensor and humidity sensor. In such cases, a historic energy meter dataset can comprise both the historic load data for the circuit and the historic environmental data; these can be communicated to the apparatus either separately or in combination.

[0066] A historic energy meter dataset can be considered as multivariate time series data that is generated by the energy meter in that it corresponds to electrical usage of a plurality of devices in the circuit connected to the energy meter, as a function of time.

[0067] At sub-step 222, for each historic energy meter dataset, the historic load data can be disaggregated into device specific historic load data fora plurality of devices in the circuit (in some cases, every device in the circuit).

[0068] In some cases, the load data can be disaggregated at step 231 , or in other cases the acquired load data can be disaggregated prior to acquisition.

[0069] The load disaggregation can be through a deep learning approach, such as with autoencoders based on the Non-lntrusive Load Monitoring Toolkit.

[0070] At sub-step 223, for each historic energy meter dataset, multivariate change event analysis can be applied to the disaggregated historic load data to determine relationships between historic events between the devices in the disaggregated historic load data.

[0071] Multivariate change event analysis can be used to assess the impact of specific events or interventions on set or related time series variables (such as voltage, current and / or resistance). For example, events can be the plugging in or switching on of a new device in the same circuit. Events can also be electrical events such as arcs, burnouts and electromagnetic interference from other devices.

[0072] This multivariate change analysis can be used to identify and understand relationships between different variables in both the short-term and long-term, to determine events in the lifecycles of the devices. At sub-step 224, for each historic energy meter dataset, historic event parameters and historic event patterns can be determined based upon the determined relationships between historic events between the devices in the circuit.

[0073] After determining the relationships and effects between different variables, statistical and machine learning analysis can be performed to find different patterns, ranges and thresholds for detection of devices in specific states. For example, this can include finding the threshold and range for current, voltage, resistance and other variables for different devices present in different states (such as burnout, arcs, EMI etc) when placed along with other devices in the circuit. These patterns and thresholds can be used to update (and therefore enhance the accuracy of) algorithms or logic present in smart devices such as an AFDD (arc fault detection device) to prevent damages caused by faults.

[0074] The patterns and thresholds for different events for different devices can be used by downstream steps, as will be discussed.

[0075] At sub-step 225, the historic event parameters and historic event patterns can be stored. For example, in the historic event datastore 113.

[0076] Storing the historic event parameters and historic event patterns can comprise storing the multivariate time series data generated by the smart meter and the environmental sensor(s) in a datastore (such as a database) along with unique device IDs.

[0077] Different thresholds, ranges and event state information of devices can also be stored as accompanying metadata.

[0078] This data can be used fortraining and evaluating machine learning algorithms later in the process.

[0079] Additionally, this database can be updated with new labelled data following event prediction, forecast and feedback (as will be subsequently discussed). In this way, continuously learning and updating of the existing algorithms can be achieved, as well as the understanding of different devices and their states.

[0080] After the training phase, the process can continue to the monitoring phase.

[0081] At step 230, the monitoring phase is performed. The monitoring phase can be performed by the monitoring module 114.

[0082] At sub-step 231 , energy meter data is acquired from an energy meter, wherein the energy meter data comprises load data corresponding to devices in a circuit connected to the energy meter. The load data can be disaggregated into device specific load data for a plurality of devices in the circuit (in some cases, every device in the circuit). That is, the load data can be disaggregated at step 231 , or the acquired load data can be disaggregated prior to acquisition. In the monitoring phase, the energy meter from which the energy meter data is acquired is the energy meter that is the subject of the electrical anomaly detection and failure forecasting. In other words, it is the energy meter for the circuit in which electrical anomalies are monitored to forecast potential electrical faults and protect electrical devices connected thereto.

[0083] The energy meter data can be acquired, for example, by the energy meter data acquisition module 111 of the apparatus 110.

[0084] The disaggregation of the load data can be performed, for example, in a similar manner to the disaggregation of the historic load data through a deep learning approach, such as with autoencoders based on the Non-lntrusive Load Monitoring Toolkit.

[0085] For example, there may be n devices in the circuit connected to the energy meter. In the monitoring phase, the events of each of these n devices are monitored by disaggregating the load data for the n devices.

[0086] The energy meter data can also comprise environmental data proximal to the energy meter that coincides temporally with the load data, such as temperature and ambient humidity of the room in which the energy meter is located, or inside a box in which the energy meter is located. This can be measured with environmental sensor(s), such as a temperature sensor and humidity sensor. In such cases, the energy meter data can comprise both the load data and the environmental data; these can be communicated to the apparatus either separately or in combination.

[0087] The energy meter data can be considered as multivariate time series data that is generated by the energy meter in that it corresponds to electrical usage of a plurality of devices in the circuit connected to the energy meter, as a function of time.

[0088] At sub-step 232, one or more events are detected in the disaggregated load data by interpretable machine learning.

[0089] These events can be considered as anomalies.

[0090] As discussed, the data originating from the energy meter after load disaggregation (and the environmental sensor(s), in some cases) creates multivariate time series data for the different devices detected on the circuit.

[0091] A global forecasting model is used for event detection for each device, separately. For example, machine learning models such as gradient boosted classification models can be used.

[0092] These models can be trained with constraints between different variables to enforce certain patterns and ranges of events device-wise, as discovered in the previous steps.

[0093] Advantageously using a tree-based model allows for the decision logic within the model to be easily interpreted and helps improve existing hardware algorithms. These models can be locally interpreted and can supply clear explanations for every incident (i.e., event), including why they were detected as a specific event.

[0094] At sub-step 233, the detected events can be compared to the historic event parameters and the historic event patterns to match the detected events to the historic events.

[0095] The ranges, patterns and thresholds for events established in the training phase can be used to compare with the model decision, with its range, threshold and events. From this, it can be confirmed if the states or events for the devices in the circuit are known events (i.e., correspond to historic events) or are unknown events (i.e., do not correspond to historic events). The events can be marked, for each device, based on the model prediction and the historic data analysis from the training phase. Detected events that match historic events can be marked as known detected events.

[0096] At sub-step 234, each detected event and parameters of each detected event can be stored.

[0097] For example, the detected events and parameters can be stored in the event datastore 115.

[0098] The events detected using the machine learning model, along with the model decision explanation, and the range and boundaries for different variables can be stored in the event datastore 115 for utilization by downstream tasks. This can be used to identify events over time in the circuit, along with the explanations for the events provided by the machine learning model(s).

[0099] At sub-step 235, it can be determined whether each detected event exceeds a predetermined threshold for the respective device.

[0100] An event can be considered to exceed a predetermined threshold for the device when a current and / or voltage and / or resistance value of the event exceeds a predetermined value that is associated with the device. For example, exceeding a predetermined voltage range for the device.

[0101] A detected event exceeding the predetermined threshold for the respective device can be indicative of a breakdown of the device.

[0102] When a detected event exceeds the predetermined threshold for the respective device, the process can proceed to sub-step 236, and a cause of the event exceeding the predetermined threshold for the device can be determined. The process can then proceed to step 250b of the feedback phase wherein user feedback is compared to the determined cause of the event that exceeded the predetermined threshold.

[0103] When a detected event does not exceed the predetermined threshold for the respective device, the process proceeds to forecasting a future impact of the event on the devices in the circuit in the forecasting phase at step 240. In other words, the decisioning performed at step 235 can compare device recommended or operational limits and analysed thresholds with the present operating state of the device, its range and its thresholds.

[0104] If the range or threshold values of different variables are out of a normal range for a particular device, the data can be investigated to determine the reason. For example, if the present state of a small and expensive device is indicative of a burnout, changes or events in the circuit can be identified as being due to a new bigger device having been added to the circuit which is causing voltage fluctuations in the circuit. As such, disruptive / disastrous events for all devices in the circuit can be identified with explanations for those events provided by event prediction models and historical data analysis.

[0105] A change in a device state due to a recent event can trigger the forecasting of a future variable value for all the devices in the circuit, which in turn can be used to detect future disruptive events in devices and their causes.

[0106] At step 240, for the forecasting phase is performed to forecast a future impact of an event that does not exceed the predetermined threshold for the respective device. This includes the impact of the event on the other devices in the circuit. The forecasting phase can be performed by the forecasting module 116 of the apparatus 1 10.

[0107] The forecasting can be performed for each of the n devices in the circuit. This is particularly useful for monitoring sensitive devices which may be negatively impacted by large devices in the same circuit.

[0108] For example, a sensitive device can be negatively affected by the presence of a large, energy- intensive device in the same circuit. In an example, a sensitive device may be a device that monitors the vital data of a patient to a high degree of accuracy, and the large energy-intensive device may be an MRI scanner; the high load of the MRI scanner can affect the accuracy of the sensitive device eventually leading to failure. In another example, the sensitive device may be a computer or television with small capacitors, and the large device may be an air conditioning system; a changing resistance due to a build-up of small faults in the air conditioning system can cause a breakdown of the television. Initially this negative effect might not cause failure in the sensitive device. However, there may be some impact causing a change in the operating parameters of the sensitive device (e.g., the operating voltage range); this change can be considered as an event in the context already described. In time, this impact can build-up stochastically (i.e., as a series of non-breakdown events for the device) on the sensitive device and eventually lead to an unexpected failure or breakdown of the sensitive device (e.g., a failure sooner than expected for the working life of the device). The forecasting phase can monitor the build-up of these negative effects on the sensitive device over time, by way of the events, and forecast when the failure might be expected to occur. This need not be limited to only sensitive devices, however; all devices in the circuit can be monitored and forecast.

[0109] At sub-step 241 , in response to the detection of an event that does not exceed the predetermined threshold for the respective device, forecast changes in values of operational parameters for the devices in the circuit due to the event can be determined with a temporal fusion transformer model.

[0110] At this sub-step, variable values for each device (such as current, voltage and / or resistance) can be forecast after a new event is detected in the circuit, and these forecasts can be used to predict the future impact on each device. For example, if there are devices in the circuit that have sensitive and small microchips, with a small range of operational electronic parameters, potential future faults can be predicted.

[0111] The use of a temporal fusion transformer model is advantageous because a temporal fusion transformer model can utilize huge amounts of multivariate data and learn patterns and dependencies between them. A multistep horizon forecast can predict multiple time series simultaneously for multiple steps in the future. This contributes to allowing the methodology described herein to generate forecasts for all devices simultaneously within a prediction interval.

[0112] The model can be explainable in that it can provide local interpretability on a case-to-case basis for future events in a given circuit. For example, if a forecast for a particular device shows a failure event in the future, the model can be used to understand the reason behind that possible future event.

[0113] In an alternative, in step 240, forecast changes in values of operational parameters forthe devices in the circuit due each detected event (rather than only those that exceed the predetermined threshold) can be determined with a temporal fusion transformer model.

[0114] At sub-step 242, potential future events for each device based on the forecast changes in values of operational parameters for the devices are determined.

[0115] After the temporal phase transformer model forecasting is performed for all of the devices in the circuit, the event detection model can be utilized for classification of the future events.

[0116] Forecasts for all of the devices in the circuit, and potential future event classifications can be added to the event datastore 115, along with the reasons.

[0117] As discussed earlier, when a detected event in the monitoring phase matches a historic event, it is marked as a known detected event. In the forecasting phase, these known detected events are beneficial to determining potential future events. The relationships between historic events between the devices in a circuit, determined in the training phase, can be used in combination with the known detected event(s) to determine the impact of the known detected events on devices in the circuit. That is to say, if it is known from the training phase in the historic data that Event A at Device A causes Event B at Device B, if Event A is identified (i.e., as a known detected event) in the monitoring phase, the impact on Device B due to the related Event B can be determined and can be used to forecast a contribution to future device failure for Device B.

[0118] The historic ambient temperature and / or humidity data from the training phase, and the ambient temperature and / or humidity data from the monitoring phase can also be used in forecasting potential future events. The training phase can comprise determining relationships between historic events and changes in I levels of temperature and / or humidity, based on the historic ambient temperature and / or humidity data. Then, in the monitoring phase, the detected events and ambient temperature and / or humidity data can be compared to the determined relationships between historic events and changes in I levels of temperature and / or humidity. When there is a match between a detected event and ambient temperature and / or humidity data with the determined relationships between historic events and changes in I levels of temperature and / or humidity, the detected event can be marked as a known detected event due to a change in I level of temperature and / or humidity. In the forecasting phase known detected events due a to a change in temperature and / or humidity are used to determine the potential future events. For example, if the historic data indicates that a rise in ambient temperature is related to Event C in Device C, which can lead to eventual device failure, the detection of a rise in ambient temperature and the occurrence of Event C in the monitoring phase can be used to forecast future device failure. Also, if the historic data indicates that a rise in ambient temperature is related to Event C in Device C, and Event C is related to Event D in Device D (and event D can eventually lead to device failure in Device D), the detection of a rise in ambient temperature and the occurrence of Event C in the monitoring phase can be used to forecast a contribution to future device failure for device D.

[0119] At sub-step 243, a notification is output indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

[0120] After the identification and classification of potential future events for each of the devices in the circuit, it can be determined whether to notify a user of the circuit (or a customer support team) of the possible issue(s) determined, along with the determined explanation / justification obtained from the models.

[0121] The forecasting can involve determining a probability or risk of the potential future breakdown of the device, based upon the forecast changes in values of operational parameters for the device. For example, if the forecast changes are changing as a function of time in a manner that is related to an increasing probability of device breakdown (e.g., a forecast increasing operating voltage), it can be determined that the probability of breakdown is increasing I has increased. The notification indicating a potential future breakdown of a device can be output when there is a change in probability of the potential future breakdown occurring. In a similar manner, the forecasting can involve determining an expected time until the forecast future breakdown is expected to occur, based upon the forecast changes in values of operational parameters for the device. For example, if the forecast changes in values of the operational parameters of the device are changing more quickly (e.g., a forecast increasing operating voltage is increasing more quickly), it can be determined that the breakdown is likely to happen sooner. The notification indicating a potential future breakdown of a device can be output when there a change in expected time until the potential future breakdown is forecast to occur.

[0122] In some examples, the outputting can be performed using the output module 118 and the output means 120.

[0123] Following the forecasting phase, the process can continue to step 250a of the feedback phase, wherein user feedback is compared to the forecasting. Step 250a can be performed by the feedback module 117 of the apparatus.

[0124] At step 250a, the feedback phase can be performed by comparing user feedback with the forecasting performed in the forecasting phase.

[0125] This feedback mechanism creates a continuous learning pipeline for the continuous improvement in algorithms and the Al I machine learning models used in the training phase, monitoring phase and forecasting phase. This adds a robustness to the methodology as new types of device or event, which are not present in historic data can be added. Additionally, integrating user feedback allows for the improvement of devices and machine learning models.

[0126] At sub-step 251 a, sentiment in feedback from a user of the circuit connected to the energy meter can be determined with a large language model. A user can be considered as an administrator, customer, operator, end-user or the like; i.e., a human who interacts with the circuit, a device in the circuit, or the energy meter.

[0127] Feedback shared by users of the circuit (and / or devices in the circuit) to which the energy meter is connected, submitted before or after the event detection and forecasting, can be provided for sentiment analysis to analyse user satisfaction and feedback on events I forecast events. The feedback is utilized to check agreement between the predictions in the forecasting events that have actually occurred, and to identify / estimate the accuracy of the models.

[0128] User feedback can be fed into a large language model to determine the sentiment in the feedback. For example, sentiment might be indicative of a device failure.

[0129] At sub-step 252a, it can be determined whether there is agreement between the sentiment in the feedback and the forecast potential future events.

[0130] For example, if it was forecast in the forecasting phase that a device is soon to fail (e.g., a small sensitive device being affected by a large device in the circuit), and the sentiment in the user feedback indicates that said device has now failed, this would be an agreement. On the other hand, if the forecasting phase did not forecast the failure of the device, but the sentiment in the user feedback indicates the device has failed, this would be a disagreement. Likewise, if the forecasting phase indicated that a device was to fail, and the sentiment in the user feedback indicates that the device has not failed, this would be a disagreement.

[0131] At sub-step 252a, when there is a disagreement between the sentiment and the forecast potential future events, the process can continue to step 253a, and the cause of the disagreement can be determined. Then, the process can continue to step 254a, and the models used in the training, monitoring and / or forecasting phases can be retrained based upon the disagreement.

[0132] If there is a disagreement between model predictions and the user feedback, a human reviewer can be provided with all the event predictions and forecasts along with the explanation for the decisions made by models and the human reviewer can validate the decision. The human reviewer can verify the claim and provides with the final decision. Then the data is added to the dataset along with events and correct label. In an alternative and / or additionally to a human reviewer, a large language model can be used to perform these steps.

[0133] When there is agreement between the sentiment and the forecast potential future events, the process can continue directly to step 254a, and the models used in the monitoring phase and the forecasting phase can be retrained based upon the agreement.

[0134] If there is an agreement between model prediction and user feedback, the data along with the events and correct label is added to the dataset and can be utilized for retraining the machine learning models used in the training, monitoring and / or forecasting phases.

[0135] When there is a conformation of the agreement or disagreement between the user feedback and the machine learning model predictions, based on the information provided, these interactions and data can be used to finetune the large language model, so that the large language model is able to learn the decisioning patterns of human reviewers for partial or full automation.

[0136] Returning to the discussion of the monitoring phase 230, following the determining of the cause of the event exceeding the predetermined threshold for the device at sub-step 236, the process can continue to step 250b of the feedback phase, wherein user feedback is compared to the determined cause of the event that exceeded the predetermined threshold.

[0137] At step 250b, the feedback phase can be performed for comparing user feedback to the determined cause of the event that exceeded the predetermined threshold.

[0138] At sub-step 251 b, sentiment in feedback from a user of the circuit connected to the energy meter can be determined with a large language model.

[0139] At sub-step 252b, it can be determined whether there is agreement between sentiment in the feedback and the determined cause of the event exceeding the predetermined threshold for the device. At step 252b, when there is a disagreement between the sentiment and the cause of the event exceeding the predetermined threshold for the device, the process can continue to step 253b and a cause of the disagreement can be determined. Then, the process can continue to step 254b, and the models used in the training, monitoring and / or forecasting phases can be retrained based upon the disagreement.

[0140] At step 252b, when there is agreement between the sentiment and the cause of the event exceeding the predetermined threshold for the device, the process can continue directly to step 254b, and the models used in the training, monitoring and / or forecasting phases can be retrained based upon the agreement.

[0141] The feedback phase 250b can substantially correspond to the feedback phase 250a, except in that in the feedback phase 250b is applied to the determined cause of the event that exceeded the predetermined threshold, whereas the feedback phase 250a is applied to the forecasting performed in the forecasting phase 240.

[0142] Figure 3 depicts a high-level block diagram of an apparatus 300 suitable for implementing various aspects of the disclosure. Although illustrated in a single block, in other embodiments the apparatus 300 may also be implemented using parallel and distributed architectures. Thus, for example, various steps such as those illustrated in the methods described above by reference to Figures 2a and 2b may be executed using apparatus 300 sequentially, in parallel, or in a different order based on particular implementations. The apparatus 110 of Figure 1 can be implemented in the form of apparatus 300.

[0143] According to an example, depicted in Figure 3, apparatus 300 comprises a printed circuit board 301 on which a communication bus 302 connects a processor 303 (e.g., a central processing unit "CPU"), a random access memory 304, a storage medium 311 , possibly an interface 305 for connecting a display 306, a series of connectors 307 for connecting user interface devices or modules such as a mouse or trackpad 308 and a keyboard 304, a wireless network interface 310 and / or a wired network interface 312. Depending on the functionality required, the apparatus may implement only part of the above. Certain modules of Figure 3 may be internal or connected externally, in which case they do not necessarily form integral part of the apparatus itself. E.g. display 306 may be a display that is connected to the apparatus only under specific circumstances, or the apparatus may be controlled through another device with a display, i.e. no specific display 306 and interface 305 are required for such an apparatus.

[0144] Memory 311 contains software code which, when executed by processor 303, causes the apparatus to perform the methods described herein. In an example, a detachable storage medium 313 such as a USB stick may also be connected. For example the detachable storage medium 313 can hold the software code to be uploaded to memory 311. The processor 303 may be any type of processor such as a general purpose central processing unit ("CPU") or a dedicated microprocessor such as an embedded microcontroller or a digital signal processor ("DSP").

[0145] In addition, apparatus 300 may also include other components typically found in computing systems, such as an operating system, queue managers, device drivers, or one or more network protocols that are stored in memory 311 and executed by the processor 303.

[0146] Although aspects herein have been described with reference to particular embodiments, it is to be understood that these embodiments are merely illustrative of the principles and applications of the present disclosure. It is therefore to be understood that numerous modifications can be made to the illustrative embodiments and that other arrangements can be devised without departing from the spirit and scope of the disclosure as determined based upon the claims and any equivalents thereof.

[0147] For example, the data disclosed herein may be stored in various types of data structures which may be accessed and manipulated by a programmable processor (e.g., CPU or FPGA) that is implemented using software, hardware, or combination thereof.

[0148] It should be appreciated by those skilled in the art that block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the disclosure. Similarly, it will be appreciated that flow charts, flow diagrams, state transition diagrams, and the like represent various processes which may be substantially implemented by circuitry.

[0149] Each described function, engine, block, step can be implemented in hardware, software, firmware, middleware, microcode, or any suitable combination thereof. If implemented in software, the functions, engines, blocks of the block diagrams and / or flowchart illustrations can be implemented by computer program instructions I software code, which may be stored or transmitted over a computer-readable medium, or loaded onto a general purpose computer, special purpose computer or other programmable processing apparatus and I or system to produce a machine, such that the computer program instructions or software code which execute on the computer or other programmable processing apparatus, create the means for implementing the functions described herein.

[0150] In the present description, block denoted as "means configured to perform ..." (a certain function) shall be understood as functional blocks comprising circuitry that is adapted for performing or configured to perform a certain function. A means being configured to perform a certain function does, hence, not imply that such means necessarily is performing said function (at a given time instant). Moreover, any entity described herein as "means", may correspond to or be implemented as "one or more modules", "one or more devices", "one or more units", etc. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional or custom, may also be included. Theirfunction may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.

Claims

Claims1 . A method of forecasting failure for electrical devices in a circuit, the method comprising: in monitoring phase: acquiring energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detecting one or more events in the disaggregated load data by interpretable machine learning; in the forecasting phase: determining, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the circuit due to an event of the one or more detected events; determining potential future events for each device based on the forecast changes in values of operational parameters for the devices; and outputting a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

2. The method of claim 1 , wherein the method further comprises: in a feedback phase: determining, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determining whether there is an agreement between the sentiment in the feedback and the forecast potential future events; when there is agreement between the sentiment and the forecast potential future events, retraining models used in the monitoring phase and the forecasting phase based upon the agreement.

3. The method of claim 2, wherein in the feedback phase the method further comprises: when there is a disagreement between the sentiment and the forecast potential future events, determining a cause of the disagreement, and retraining models used in the monitoring phase and the forecasting phase based upon the disagreement.

4. The method of any preceding claim, wherein the method further comprises determining whether each detected event exceeds a predetermined threshold for the respective device, and performing the forecasting phase for an event of the one or more detected events when the event does not exceed the predetermined threshold for the respective device.

5. The method of claim 4, wherein the method further comprises: determining a cause of the event exceeding the predetermined threshold for the device when a detected event exceeds the predetermined threshold for the respective device.

6. The method of claim 5, wherein in the feedback phase the method further comprises: determining, with a large language model, sentiment in feedback from a user of the circuit connected to the energy meter; determining whether there is agreement between sentiment in the feedback and the determined cause of the event exceeding the predetermined threshold for the device; when there is an agreement between the sentiment and the cause of the event exceeding the predetermined threshold for the device, retraining models used in monitoring phase and the forecasting phase based upon the agreement; and when there is a disagreement between the sentiment and the cause of the event exceeding the predetermined threshold for the device, determining a cause of the disagreement, and retraining models used in monitoring phase and the forecasting phase based upon the disagreement.

7. The method of any one of claims 4 to 6, wherein a detected event exceeding the predetermined threshold for the respective device is indicative of a breakdown of the device.

8. The method of any preceding claim, wherein: the energy meter is a smart electricity meter and the circuit comprises devices connected to the smart electricity meter; or the energy meter is connected to a vehicle, and the circuit comprises electrical devices of and / or connected to the vehicle.

9. The method of any preceding claim, wherein the method further comprises: in a training phase: acquiring a plurality of historic energy meter datasets, wherein the historic energy meter datasets are from a plurality of energy meters, and each historic energy meter dataset comprises historic load data that is disaggregated into to device specific load data for a plurality of devices in a circuit connected to a respective energy meter of the plurality of energy meters; for each historic energy meter dataset, applying multivariate change event analysis to the disaggregated historic load data to determine relationships between historic events between the devices in the disaggregated historic load data; for each historic energy meter dataset, determining historic event parameters and historic event patterns based upon the determined relationships between historic events between the devices in the circuit; and storing the historic event parameters and historic event patterns.

10. The method of claim 9, wherein in the monitoring phase, the method further comprises comparing the detected events to the historic event parameters and the historic event patterns to match the detected events to the historic events, and when a detected event matches a historic event, marking the detected event as a known detected event; wherein in the forecasting phase, known detected events are used to determine the potential future events based upon the determined relationships between historic events between the devices in the training phase.11 . The method of claim 10, wherein: the historic energy meter dataset further comprises historic ambient temperature and / or humidity data proximal to the energy meter as a function of time; the energy meter data further comprises ambient temperature and / or humidity data proximal to the energy meter as a function of time; and wherein the training phase further comprises determining relationships between historic events and levels / changes of temperature and / or humidity, based on the historic ambient temperature and / or humidity data;wherein the monitoring phase further comprises comparing the detected events and ambient temperature and / or humidity data to the determined relationships between historic events and levels / changes of temperature and / or humidity, and when there is a match between a detected event and ambient temperature and / or humidity data with the determined relationships between historic events and levels / changes of temperature and / or humidity, marking the detected event as a known detected event due a to a level / change of temperature and / or humidity; and wherein in the forecasting phase known detected events due a to a level / change of temperature and / or humidity are used to determine the potential future events.

12. The method of any preceding claim, wherein an event comprises one or more of a change in voltage, current and resistance of a device in the circuit.

13. The method of any preceding claim, wherein the notification indicating a potential future breakdown of a device is output when there is a change in probability of the potential future breakdown occurring and / or a change in expected time until the potential future breakdown is forecast to occur.

14. An apparatus configured to forecast failure for electrical devices in a circuit, the apparatus comprising: a monitoring module configured to perform a monitoring phase, wherein the monitoring module is configured to: acquire, with a data acquisition module, energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detect one or more events in the disaggregated load data by interpretable machine learning; a forecasting module configured to perform a forecasting phase, wherein the forecasting module is configured to: determine, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the circuit due to an event of the one or more detected events; determine potential future events for each device based on the forecast changes in values of operational parameters for the devices; andoutput, with an output module, a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

15. A computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps: in monitoring phase: acquiring energy meter data from an energy meter, wherein the energy meter data comprises load data that is disaggregated to device specific load data for a plurality of devices in a circuit connected to the energy meter; detecting one or more events in the disaggregated load data by interpretable machine learning; in the forecasting phase: determining, with a temporal fusion transformer model, forecast changes in values of operational parameters for the devices in the due to an event of the one or more detected events; determining potential future events for each device based on the forecast changes in values of operational parameters for the devices; and outputting a notification indicating a potential future breakdown of a device in the circuit based upon the forecast potential future events.

Images