Patent Application
20180034657
The present invention relates to a method and system of monitoring appliance usage within a building.
There are many devices or appliances in dwellings, from individual light fittings, through televisions to major energy users, such as boilers and tumble dryers. In future, some of these devices may be smart, so that they declare their presence and their status can be read, including the possibility of control, such as turning lights on and off to discourage burglars, scheduling drying when power is cheap etc. Some devices will already have this capability (such as Smart TVs and heating systems), although most do not. Understanding patterns of occupancy, appliance use and utility consumption in dwellings currently requires unaffordable levels of instrumentation. Although sensors may eventually be embedded in all devices, including lighting, the timescale for it to be normal to find this level of embedded sensors in the domestic environment is likely to be significantly in excess of fifteen years. Buildings environmental management is a key element in future utility supply and use, both in terms of energy efficiency, costs budgeting and improving user control and experience.
The existence and usage of appliances within a building can be recognised by inference from their utility usage signatures. The principles for this have been described in U.S. Pat. No. 4,858,141 and are now encompassed within a community of practitioners of Non-Intrusive Appliance Load Measurement (NIALM) for example, as described in “Is Disaggregation The Holy Grail Of Energy Efficiency? The Case Of Electricity”, K. Carrie Armel, Abhay Gupta, Gireesh Shrimali and Adrian Albert, Energy Policy, 2013, vol. 52, issue C, pp 213-234. While the concepts of this technology have been recognised for some time, its application in practice has been limited by a failure to integrate various elements effectively into a practical solution. In U.S. Pat. No. 4,858,141, and other subsequent publications, data is gathered from electric power usage measurements. Using data from utilities other than electricity, and taking additional factors/data into account, has been touched on by various sources, some of them in U.S. Pat. No. 4,858,141. However, the prior art neither teaches how these concepts should be implemented individually and in effective combinations, nor how they should form part of an effective overall Building Environment Management System (BEMS).
The present invention has therefore been designed with the foregoing in mind.
Monitoring appliance usage is central to the effective operation of a Building Environment Management System (BEMS). Not only does it provide data about energy usage, but more importantly it provides information about patterns of activity and use of the building by the occupants which can enable the BEMS to better manage the building environment to fit with these patterns of occupation. Nowhere is this more true than for a Home Environment Management System (HEMS). People spend more time at home than in any other building; they show the widest range of activity patterns at home; and they expect to have the most control over their domestic environment. Implementing appliance monitoring on its own will provide information on patterns of utility use. Integrating it into a HEMS will enable information about patterns of occupancy to be used, for example in scheduling a heating system. Also the HEMS can provide additional information to an appliance usage module, for example, that a temperature rise in a living room is consistent with a gas fire being in operation. The prior art does not discuss or teach about the implementation of these functionalities in any coherent way.
For the sake of brevity, the specification tends to refer to a HEMS only. It should be understood that the invention can also be applied to any BEMS, not just a HEMS.
According to a first aspect of the present invention there is defined a method of operating an environment management system within a building as defined in claim 1. The method comprises: monitoring appliance usage by monitoring two or more utilities and measuring one or more characteristics relating to each of the utilities to provide an output signal representative thereof; monitoring for changes in the state of each of the output signals at predefined time intervals; combining data from the output signals from each utility, to identify one or more patterns of appliance usage; comparing the identified pattern of appliance usage with stored patterns of appliance usage associated with individual occupants of the building to identify an expected pattern of future appliance usage; and operating the environment management system to control the environment in the building in accordance with the identified expected pattern of future appliance usage.
The invention enables complex patterns of utility usage to be used to extract information on what appliances are present within a building and the activities of a person or persons within the building whilst those utilities are being utilised. Advantageously, the method enables deduction of appliance usage patterns, and identification or recognition of appliances or the state of appliances, in a relatively inexpensive way. This is because a low cost set of measurements on utilities at the point of entry into a building can replace or enhance what would otherwise be a much higher number of sensors distributed around the building and its appliances and systems. This in turn adds value to consumers in assisting them to manage their energy use effectively.
Using more information obtained from monitoring the utilities can allow more details to be determined about the patterns of occupation in the building (i.e. identifying a light switch signature alone would not allow the location of the light to be determined without taking into account other factors—e.g. a tap is running in the bathroom early in the morning so the light is likely to be in the bathroom). Monitoring more than one utility (e.g. electricity and water and possibly also gas) therefore helps to determine which appliances are being used based on expected or probable patterns of appliance usage.
The patterns of appliance usage might comprise recognising that a particular appliance is used at a particular time of day/week (e.g. a washing machine is always operated on a Monday, or a user always fills and boils a kettle when they arrive home after work).
If a single instance of utility usage is considered in isolation (as is the case in the prior art) it is not always possible to determine the appliance in question. For example, a similar amount of water may be used when flushing a toilet and when washing hands. In which case, prior art methods will be unable to distinguish between these two activities. By contrast, the present invention can use additional information (e.g. a noise signal) to distinguish between the sound of a tap valve opening and the sound of a flush valve opening to determine which appliance is being used.
It is possible to identify operation of a motor because it will have a phase angle associated with its use.
Operation of a dishwasher may be distinguished from a washing machine due to the presence of a drying cycle (comprising heating without water usage) in only the dishwasher and/or the presence of a spin cycle (comprising a motor without water usage) in only the washing machine.
The two or more utilities may comprise water and electricity. Gas may be monitored instead of or in addition to electricity. Other utilities may also be monitored.
The step of identifying patterns of appliance usage may comprise using a priori probabilities and firstly comparing reference patterns of appliance usage that are determined to be most likely, with the data. For example, if water is flowing first thing in the morning at the same time as a pump is running, the system may hypothesise that an occupant is having a shower.
Appliances in the building may constitute a system and the system may be represented as a finite state machine and each output signal may represent a state of a characteristic of the system at a particular time.
According to a second aspect of the present invention there is defined a method of operating an environment management system within a building as defined in claim 4. The method comprises: monitoring appliance usage within a building, wherein appliances in the building constitute a system and the system is represented as a finite state machine; monitoring two or more utilities and measuring one or more characteristics relating to each of the utilities to provide an output signal, each output signal representing a state of a characteristic of the system at a particular time; monitoring for changes in the state of each of the output signals at predefined time intervals; combining data from the output signals from each utility, to identify one or more patterns of appliance usage; and operating the environment management system to control the environment in the building in accordance with the identified patterns.
In embodiments of the first or second aspects, the system may be represented as a Markov chain.
The measurement of said one or more characteristics may be recorded within a measurement bin of predetermined size, said bin being within a predetermined measurement range.
The method may further comprise defining a work process based on a pattern of inputs to an appliance over time.
The method may comprise defining a work flow based on identifiable sequences of work processes across one or more appliances.
The step of identifying one or more patterns of appliance usage comprises determining a utility usage pattern for an appliance based on processing of said output signals and analysis of identified work processes and work flows.
The method may comprise comparing one or more of said patterns of appliance usage with one or more reference patterns to identify the appliance with which the output signals are associated.
The method may comprise evaluating the probability that an appliance exists within the building based on said comparison.
The method may comprise comparing one or more of said patterns of appliance usage with one or more reference patterns to infer an indication of the existence, location and/or usage of one or more appliances within said building.
The a priori probabilities may include frequency distributions of work flows.
The a priori probabilities may include exogenous factors and hypotheses about the occupation state of the building.
The method may further comprise modifying the a priori probabilities associated with patterns of appliance usage hypothetically arising from work flow(s), work process(es), appliance(s) and/or component(s) of appliance(s) by reference to stored data on historic appliance usage.
The historic appliance usage may relate to one or more appliances in one or more other buildings and the a priori probabilities may be determined dependent on the geographical distance of another building relative to the said building.
The method may further comprise representing one or more reference appliances in a computer language whereby the pattern of appliance usage is derived from defined processes operating on defined components within the appliance.
The language may enable specific instances of appliances, processes and components to be created by class inheritance.
The reference appliance pattern may be acquired from an electronic signature, barcode or Qcode present on or related to said appliance.
The probabilities may be derived from a combination of analysis of central data and user input.
The characteristics may comprise one or more of flow variables, noise variables or quality variables.
The characteristics may comprise one or more of voltage, RMS voltage, calorific value, phase angle, power, real power, reactive power and colour.
According to a third aspect of the invention there is provided an apparatus for operating an environment management system within a building, comprising apparatus for monitoring appliance usage within the building, comprising a plurality of measurement devices, each configured to measure one or more characteristics relating to a particular one of two or more utilities and to provide an output signal representative thereof; and a processing device configured, in response to the combination of said output signals from each utility, to: monitor for changes in the state of each of said output signals at predefined time intervals and combine information from a plurality of output signals to identify one or more patterns of appliance usage; to compare the identified pattern of appliance usage with stored patterns of appliance usage associated with individual occupants of the building to identify an expected pattern of future appliance usage; and to operate the environment management system to control the environment in the building in accordance with the identified expected pattern of future appliance usage.
According to a fourth aspect of the invention there is provided an apparatus for operating an environment management system within a building, comprising: apparatus for monitoring appliance usage within the building, comprising a plurality of measurement devices, each configured to measure one or more characteristics relating to a particular one of two or more utilities and to provide an output signal representative thereof; and a processing device configured, in response to the combination of said output signals from each utility, to: monitor for changes in the state of each of said output signals at predefined time intervals and combine information from a plurality of output signals to identify one or more patterns of appliance usage, wherein appliances in the building constitute a system and the system is represented as a finite state machine, each output signal representing a state of a characteristic of the system at a particular time; and to operate the environment management system to control the environment in the building in accordance with the identified patterns.
Advantageously, aspects of the invention enables inference of appliance existence/usage within a building based on combining multiple signals relating to different utilities and, more specifically, to different components or characteristics of the different utilities.
Ideally, components of appliances will be manufactured so that a probability distribution of their utility usage signatures will be large enough and well-distributed enough to maximise the chance of disambiguation by the HEMS. If the distribution is known and supplied by the manufacturer, it can be used by the HEMS as an input to the disambiguation process for identifying appliances, either where the component parameter values are measured, and supplied together with the range, or where the range alone is supplied with the component. Furthermore, appliances are ideally assembled using components where the parameters of the work processes (for example exact duration of a step in a wash cycle) are sufficiently distinct to increase disambiguation in a similar manner to the above.
In effect, aspects of the invention relate to a HEMS that assesses the state of the entire system at regular points in time and tries to determine what is happening. This may include determining what components are being used, what appliances are being used, what work processes are being used and what work flows are in operation. In other words, the system uses utility data to accurately build up a real-time picture of the activities being undertaken in the building at any point in time and may use this to predict a work flow so that the likely energy usage can be supplied. This is contrary to the prior art which relies on nice clean step changes from single utility measurements to identify individual appliances.
In addition, the HEMS may conduct a historical review (or calibration process) to consider the utility usage signatures for unidentified components, appliances, work processes or work flows and to hypothesis about what these might be. The historical review may be programmed to run at regular intervals and/or whenever a new component, appliance, work process or work flow is encountered. The historical review may compare data with that from other HEMS, particularly from buildings geographically close to the building concerned.
Embodiments of the invention will now be described, by way of example only, with reference to the Figures of the accompanying drawings in which:
Aspects and embodiments of the invention thus provide for recognition of patterns of appliance usage within a building. This is achieved by combining utility signals such as those relating to electricity, gas and water usage, together with any other relevant energy related flows, and possibly information from other sensors (such as smart devices and those that are part of heating/security systems, for example). The utility usage pattern of each appliance or device can be recognised by (a) primary processing of the signals (e.g. the typical high frequency noise and shape of the signal output of the combination of the components of devices), (b) work process (the pattern of inputs to a device over time, for example the wash and dry cycle on a dishwasher) and (c) workflow (the human use of devices in combination—washing clothes in a washing machine then tumble drying them, or turning lights on, then the TV, then an electric shower). Aspects and embodiments of the invention utilise the disambiguation of energy use patterns subjected to hypothesis testing over many repeat samples to provide a statistical hypothesis relating to on-going instances.
The system architecture of the HEMS is not described in detail as such is known in the art. At a high level, this can be described as an appropriate combination of (a) processes running on hardware located in the specific building (including sensors and effectors), (b) an internet connection, (c) an application running on a personal device (such as a mobile phone or tablet), (d) additional data and processing capability in a shared central server (for example in the cloud) and (e) a web based client for use on any internet connected device.
The HEMS is foreseen as part of an integrated system. Although in principle it would be possible to implement a cut-down version that acts as a stand-alone system, this would not be able to provide all of the value of the full concept and the local HEMS hardware would need to be significantly more powerful (and costly).
In a particular embodiment, the cloud service would be a private service provided by a particular HEMS service provider. The design of IT hardware and system architecture to provide this is a matter of system design optimisation. The selected architecture may vary from provider to provider for a variety of reasons and the dominant design will certainly change with time as IT continues to develop. None of this detail is important to the present invention, except insofar as the optimisation succeeds in delivering the required services effectively and at an acceptable cost.
We therefore consider an abstraction where all the services are provided from a notional or virtual central server (with backup). System resilience, capacity optimisation, scalability and so on would be addressed in the detail of the architecture.
This central server would be operated or controlled by the HEMS service provider and would also link to wider business services such as payment systems (for billing the customer), weather data and forecasts, energy market operation etc. These wider services would be integrated into the service provided to the HEMS user by the HEMS service provider. Some of these services have an obvious and direct impact on what the user sees, such as weather data or entering billing information; some of them are not normally directly visible to the user, such as wholesale energy market transactions.
The central server could be used to provide a range of classes of service across the population of HEMS that it supports:
The primary customers for the statistical and analytical services are individual HEMS users, however there are other possible users:
Whether data on individual users is completely accessible to the service provider would need to be determined. For example, a selling point for some mobile phone operators is that their devices provide strong encryption, so that the operator cannot access e-mails and contact details etc. How much protection can be provided to users of the HEMS without compromising service provision is unclear and would be a matter for detailed design.
In principle, individual user data may only be unencrypted where that is necessary to provide a user service. For example, the data backup for each user may not be associated with the user account but with a code known only to the HEMS associated with that particular user. Therefore the HEMS can access and unencrypt the data but no-one else can. The system backup for the HEMS contains the code but encrypted, so that only a hardware key in the HEMS can access the backup. Individual user data may be stored unencrypted but only where it cannot be associated with the user.
These are not technically trivial issues. It is well known that it is possible to provide privacy for users by anonymising individual pieces of data but then possible to put together anonymised sets of data with identified data in a way that unlocks the anonymised data. For example, if there are ten million detailed sets of data from HEMS, but with no links to individual users, it may be possible to identify many individual users armed with their billing address, monthly energy usages and detailed local weather histories.
The implementation of consumer protection measures is not addressed further in this application but there is an assumption that the naïve model of all the data being available to a “central engineer”, who has delegated the analytical task to a computer programme, is not the one that is intended.
The most difficult area in relation to consumer protection is likely to be geographic proximity. Some of the HEMS analyses use geographical information in estimating a priori probabilities, for example that people living closely together are more likely to have similar patterns of behaviour or that new appliances will initially appear in clusters due to stocking patterns in shops and word of mouth recommendations. (The counterfactuals of national launch and recommendations via social media would also need to be considered against real launch data).
Advantageously, the utility data collected can be used to:
These purposes are not clearly identified in the prior art, which over-emphasizes electricity as a single utility and confuses the identification of major energy usage with the identification of human and autonomous activity patterns. Also, it is not known in the prior art to integrate appliance recognition with the control functions of a HEMS. Thus, embodiments of the present invention recognise that some of the inputs required by the HEMS are automatically known to it or it can obtain these directly. For example, the HEMS may know the status of a (gas) boiler or an air-conditioning system, or if a movement sensor of a security system is triggered. Given the degree of control that a HEMS is required to deliver over some of these systems, this information could be quite complex. For example, data from a heating system could include water temperatures and room temperatures in different parts of the system, boiler firing data and water storage tank temperatures. Remote controlled gas fires may be able to share data on temperature set point and smart televisions monitor environmental light levels and can control display brightness in response etc.
Aspects and embodiments of the invention are thus useful in managing and monitoring the home/building environment including where utilities of different types are being used, and what occupants of the home/building are doing when those utilities are being used.
If all possible activities were to be searched every time a utility were used, the size of the computation would be prohibitively large to implement a practical system. Embodiments of the present invention overcome this limitation through use of a priori Bayesian Statistics such that the most likely activities are compared first to reduce the size of the computation and speed up the analysis.
It should be understood that the diagram in
The measurements for each utility may comprise one or more of:
1) Amount of value per unit of flow (electricity is voltage, water is constant density, gas would be calorific value but it is too expensive to measure it at each house and the data can be supplied from a central point).
2) Flow rate (electricity is current, water is cubic metres per second, gas is nominal cubic metres per second) (for water and gas the meter provides a “pulse” when the next amount has flowed through).
3) Noise (i.e. the information contained in very fast changes in flow rate). One can hear this for water in a house as thuds, hisses and whooshes. Wth a sound card, one can do the same for electricity. Gas is compressible, so there is no useful data in this category. It should be noted that the supply may already contain some noise from outside (e.g. travelling down the pipes and wires).
Electricity is unusual in that voltage varies with time (50 Hz nominal mains frequency). There is therefore extra information about the load in the “phase angle”, the amount by which the current leads or lags the voltage.
In order to have manageable mathematics, the noise is taken as “sound” level in frequency ranges or bins.
It is worth noting that the number of bits and chipsets employed will be determined based on a cost benefit analysis, both in terms of signal processing capacity in the measurement device and also later in relation to the size of the mathematical problem in determining what is happening. If standard sixteen bit chipsets are used they can be obtained at reasonable cost. The cost for longer word lengths would be significantly greater but such word lengths could generate more information. In which case, it would take much longer for the HEMS to solve the equations required and so there is a trade-off between cost and complexity. In some embodiments, less than the full resolving power of sixteen bits may be employed. In other embodiments, 24 bit chipsets may be employed.
Regarding the length of time over which the signal may be averaged for each utility, it worth noting that, in general, we are trying to discriminate events which happen fairly quickly (like switching on a light, going to the sink and turning on a tap). Data compression will allow the storage of data where not much is happening, and so the aim would be for the signals to be measured over a small enough time frame to have real data (i.e. to notice some changes). It is expected that events like switching on an appliance or opening a valve (e.g. tap) will generate enough information to be of value in approximately a one second timescale. Gas is compressible, so the signals relating to gas are smoothed out and it will probably not be worthwhile sampling the gas signal more often than once in every ten seconds. If the sampling is less often than every ten seconds it may not be possible to determine how long it takes a user to turn on a gas ring after entering the kitchen. Again, ten seconds may be shorter than is possible or than is required but the amount of data gathered at such a sampling rate will not be excessive.
It should be understood that all of the measurements will be quantized by both the mathematics of IT (i.e. processing hardware) and also physics. For example, it is possible to calculate pi to an arbitrary number of decimal places but a sixteen bit word will only give decimal numbers to a limited precision. Even with longer words, the underlying signal to noise properties of the sensor and analogue to digital converter, and the drift or reproducibility of the device, will limit the accuracy with which it is useful to report measurements. The question is how small a change can be measured. Conceptually, we can represent the system as a finite state Markov Chain, i.e. it can only have a finite number of sets of measurement values at one time point (albeit very large) and the system moves from one state to the next at the measurement time steps (defined transitions in our Markov Chain). This will allow recognition of patterns of appliance use as a set of additive states over a period of time (e.g. light on, then dishwasher starts). In order to prevent an excessive size of the system (in terms of data), the number of states should be limited accordingly.
In relation to temperature measurements, a low-cost digital sensor (e.g. DS18B20) can report temperature to a moderate precision in up to twelve bits. This allows the sensor to report temperature in steps of 0.0625 degrees C. (precision). The operating range is −55 to +125 degrees C. The accuracy is 0.5 deg C., in the range −10 to +85 degrees C., and the reproducibility is estimated to be around the same value as the precision. Accordingly, if the sensor reports 21.1 degrees C. today that is similar to 21.1 degrees C. yesterday, but the two sensors are also considered to be reading the same if one reports 21.1 deg C. and the other reports 21.6 deg C. (although they could be further calibrated). For building physics purposes, a temperature precision of around 0.1 deg C., reproducibility of around 0.2-0.5 deg C. and accuracy of around 1 deg C. would be desirable so a sensor of the type described above would be suitable.
Different utilities will be characterised by different utility “properties”, which can be measured to provide information on the utility as it enters or is provided to the building. The signals 34, 36, 38, 40 may comprise a plurality of “signal channels” or “measurement channels”, each relating to individual or predefined combinations of utility properties. That is to say, the properties that characterise the amount of water being consumed will differ from those relating to gas, electricity or other utilities.
For example, the properties describing water will include volumetric flow data, and colour spectrum in the frequency range substantially from 60 Hz to 44 kHz. (Colour in this context is used as shorthand to describe the set of noise data about signal levels in the range of frequencies 60 Hz to 44 kHz, i.e. the frequency profile.) This range represents a frequency from just above the mains frequency to the typical limit of a sixteen bit chipset as would be found in the measurement device 10. Monitoring signals at frequencies above 44 kHz is not excluded, but this would add to the cost. Water flow colour can advantageously be derived from a “microphone” type of sensor rather than by analysis of the primary flow signal, to reduce the sensor cost. The data collected will typically be averaged over approximately one second, i.e. flow events can be located in time to one second accuracy. It will, however, be appreciated that a different accuracy could be used if required, e.g. approximately 0.5 s, 1.5 s, 2.0 s.
Gas requires only energy flow data at an approximately ten second resolution, so that utility events can be aligned across all utilities at this time resolution. Again, a different resolution may be employed, e.g. 5 s, 6 s, 7 s, 8, 8.5 s, 9 s, 9.5 s, 10.5 s, 11 s, 11.5 s, 12 s, 13 s, 14 s, 15 s etc.
Electricity has the most complex signal output, including RMS voltage, real power, reactive power and colour at one second resolution. It will, again, be appreciated that a different accuracy could be used if required, e.g. approximately 0.5 s, 1.5 s, 2.0 s.
For each utility being measured, the measurement devices 10, 12, 14, 16 produce one or more digitised signals representative of a property of the utility. It is preferable for incoming electricity and water flows to have a high time resolution (e.g. 1 s) to capture the information as transient changes occur. Gas (or oil) flows, however, are only required at a lower resolution (e.g. 10 s) as this is sufficient to detect usage events.
Other utilities can also be measured where they impact on energy use within the building. The most likely additional or alternative utilities are steam, hot water and chilled water. Given the significant thermal mass of most systems handling these utilities, colour is unlikely to provide a valuable set of signals, and a resolution of approximately ten seconds is likely to be sufficient. Inlet temperature, outlet temperature and energy flow are the most likely valuable parameters to measure for hot and chilled water. Inlet steam flow, temperature and pressure and condensate temperature are the most likely valuable parameters for steam supply.
In accordance with their standard modes of operation, the “primary” measurement devices 10, 12, 14 will produce the corresponding measurement signals 34, 36, 38 as an instantaneous value, averaged over the sample duration, for example approximately one second for electricity or water, and less for the other “secondary” utilities. (Although the “secondary” utilities (measured by measurement device(s) 16 to produce signal(s) 40 are not further specifically discussed herein, data derived therefrom can be collected and processed in a manner that is analogous to the processing of gas, water and electricity data as is described.) The measurements are provided as signal levels in frequency bins, the width of which can be chosen to provide a mathematically logical signal to noise ratio.
On receipt of the signals 34, 36, 38 the HEMS 4 will:
An important feature of the first aspect of the invention is monitoring for changes in the “state” of each of the output signals 34, 36, 38 at predefined time intervals. That is to say, a finite state analysis is performed on each of the signals 34, 36, 38. In an embodiment, the utility data is conceptualised as a Markov Chain of sequential states of the system. That is to say, the system (i.e. the HEMS 4 including the appliance recognition module 2) monitors each individual measurement channel over time to determine whether it remains in the same state as in the previous time period or whether it changes. The time periods are dictated by the resolution chosen or predefined for each utility as discussed above. The system detects these changes by treating the detected signals 34, 36, 28 as a set of quantized states within the measurement range and time resolution of the individual measurement channel. This is exemplified in
Herein, at time step n (i.e. at tn depicted along the horizontal axis) the signal channel 34, 36, 38 is in the range of the vertical axis shown by the shaded box. This lies within the overall signal range of Rmin to Rmax, which is divided into a series of measurement states. The size of each of these boxes (i.e. data blocks) is the larger of:
The measurement devices 10, 12, 14, 16 are unlikely to have perfectly linear responses over their measurement full range and, as such, the boxes for any one channel are likely to be of different sizes. For simplicity, however, the example of
The first two criteria listed above are programmed into the system at an initial stage e.g. on installation within the building and the third is estimated after an initial learning period and subsequently re-calibrated with time, based on on-going system learning. There are a variety of methods for establishing the background noise on a measurement channel. One approach is to partition the state transitions on each channel over a training period e.g. of two to three days and to take the 50% of transitions which are smallest (including null transitions), according to a predefined threshold, as representing noise and the other 50% as representing signal (including null transitions). All utility measurement devices are likely to produce more than one signal channel (apart from gas, where noise is unlikely to be an issue), so the signal and noise of channels is compared so that any presumed signal on one channel is accompanied by a presumed signal on at least one other channel. Where this is not the case, then the smallest 90% of initially presumed non null transitions are reclassified as noise. The boundaries of the boxes are recursively adjusted across the channels of each measurement device 10, 12, 14, 16 until the above rules are satisfied. Where the finite states of any channel are significantly less (e.g. fewer than 85% of the number expected from the inherent characteristics of the measurement device), then a report is generated in a HEMS 4 log. The potential causes of a noisy channel are (a) failure of the measurement device 10, 12, 14, 16, (b) a noisy component of an appliance 7 in constant operation and (c) noise injection from the utility supply. Each of these situations represent challenges for embodiments of the present invention, and also potential failures requiring maintenance attention, starting with a diagnostic step which could be automated based on signature analysis gathered from many installed HEMS 4 over a period of time but initially requiring human diagnosis. The system carries out this noise analysis periodically, nominally e.g. once a week.
At time step n+1, i.e. at tn+1 in
The time steps of the horizontal axis are preferably predefined, equal time steps e.g. 1 s, 10 s, as discussed above. The signal range depicted by Rmin to Rmax in
Recent data collected in this way, e.g. the last 24 hours of Markov Chain data, may be retained in the working memory (e.g. storage unit 8) and older data may be sent to a data store (e.g. central storage unit 8′). Alternatively, the HEMS 4 may retain historic data in working memory and send incremental data to the data store 8′.
Some, if not all, appliances use water and electricity in defined patterns or utility/energy usage signatures. For example, a dishwasher may have a number of settings that a user can choose but, for each, the cycles that it goes through (washing, rinsing etc.) at predetermined temperatures for predefined times is the same every time that setting is chosen. The energy usage patterns are likely to vary between appliance models, and between manufacturers etc., but it is possible to know the expected utility (water, gas) signature pattern for a particular appliance/model. Building on this, at a basic level, not all appliances use water, and so looking for an indication of water usage and/or electricity usage, and also if there is any gas usage, and whether these usages fit the known patterns for various appliances, can enable recognition/identification of an appliance. Another key pattern is that associated with lights. The energy signature for a light is recognisable, and identification of a light being used will identify the room of the building in which an appliance is being used. This information can be used to assist in disambiguating between possible alternative explanations (i.e. a measured combination of water, electricity and or gas usage signals can be compared against known signatures of utility usage combinations characteristic of various appliances in order to test or hypothesise what appliance is likely to be producing the measured signals).
Knowledge obtained from monitoring energy/appliance usage within a building can also be used to make inferences about how occupants of the building use various appliances 7, and the HEMS 4/appliance recognition module 2 can define and test hypotheses to understand what the measured data means.
For example, if, early every morning, it is known that a light is turned on and in that room water and electricity are used, then the light is turned off and then electricity is used in another room, it can be hypothesised that a person has gone into a bathroom and had a shower and then gone into their bedroom to dry their hair with a hairdryer. The combination of different energy signatures, in different locations and at different times, provides an indication of what appliance(s) is(are) being used and a person's activities in using those appliances. This enables identification of appliances, and use of appliances within the building. If a previously unknown electrical energy signal were detected shortly after the above process were carried out each morning, it could be further hypothesised that the person had purchased some hair straighteners and was straightening their hair. Information from other sources could also be used in developing the hypotheses e.g. a sensor that detects a relative rise followed by a drop in humidity would further support the hypothesis of appliance usage in a bathroom.
The appliance recognition module 2 receives inputs from the HEMS 4 on:
This is exemplified in
There is also a historic review process, especially in relation to unidentified patterns. This generates alternative hypotheses about the causation of utility usage patterns and tests their probability of matching a reference appliance/device using information relating to utility usage repeat patterns until the combination of tests provides statistically significant disambiguation. Other information, such as geographical information, or further information from other sensors employed within the building may also be utilised to help identify appliances 7. Thus, the “a priori probabilities”, e.g. the a priori Bayesian probabilities, associated with patterns of appliance usage hypothetically arising from work flow(s), work process(es), appliance(s) and/or component(s) of appliance(s) can be modified by reference to a central history database of these items from other buildings in the same geographic region as the specific building being monitored. The a priori probabilities can be determined by studying the spatial relationships within the central database held in the remote storage device 8′ on the hypothesis that buildings closer to the building in question are more likely to represent it than those further away. Sufficient data is selected to provide a strong hypothesis based on correlations with distance (e.g. assuming inhomogeneity in a pseudo two-dimensional plane). In an embodiment, user input, by e.g. an installation engineer for the system or a user of the system, can be combined with the central data in determining the a priori probabilities. In another embodiment, other information gathered through the installation, setup and operation of the HEMS 4 contributes to the a priori probability inputs.
Furthermore, information created by appliance monitoring can be used as an input to other modules/units 6 of the HEMS 4 including, but not limited to: identification of secondary heating and cooling appliances and their usage for the purposes of environmental control, calculation of utility usage within the building and its allocation to appliances 7, work processes and work flows for the purposes of budgeting and resource optimisation, identification of patterns of occupation for the purposes of control optimisation, identification of patterns of behaviour for the purposes of identifying hidden Markov changes in the status and wellbeing of occupants, etc. Gathering data on the usage and performance of appliances 7 in buildings can also provide valuable generic information to appliance manufacturers, standards setters and regulators on their reliability, patterns of use, achieved efficiency etc.
Aspects and embodiments of the invention thus rely on a combination of upfront (stored) input data representative of typical device patterns, disambiguation within an individual building against workflows, and disambiguation across many buildings of work processes. With a sufficiently large population of installed HEMS, the central server (or a supervisory module linked thereto) may be able to identify the entry of new devices into the market and enable central decisions about the value of additional investigations (e.g. using the data gathered from each HEMS the system may look for external evidence of new devices, for example, using the internet). The signatures of large utility-using devices/appliances are highly likely to be distinctive. For example, gas fires and fan heaters emit unexplained heat, tumble dryers and showers use a large amount of electricity but only one uses water etc. In addition to being able to recognise that new devices, work processes and workflows are in use in the building, the pattern recognition has the potential to recognise developing faults and deterioration of performance. The central server could therefore share this information with manufacturers.
Appliance use is described by a hierarchy as exemplified in
Each individual HEMS in a set of many HEMS operated by a HEMS service provider (via a central server) is working with data on appliances in a particular building, as described above in relation to
Known components which cannot be assigned to an appliance by an individual HEMS or by the central server may be logged in central database but the added value of doing this and risks of this are unclear and the main focus is on appliances that the HEMS has identified. The only component class for which this is likely to be important are the individual elements of lumieres—“lightbulbs”.
Each HEMS will also have utility usage which it is not able to assign unambiguously to appliance or component classes—for example a mains powered smoke detector and a wireless router will be hard to detect from the very limited data the system can collect about them. Given the main purposes of the HEMS (to capture patterns of human occupancy and to analyse and control utility usage), disambiguating background electricity usage is not that important. If someone is really interested, they can disconnect each appliance in turn to see its power consumption. However, it is expected that less than 5% of users will want to do that and it is easy to create a scheme to enable it.
Individual HEMS and the central server work together to recognise and collect data on appliances. The central database logs and tracks all instances of group (3) above and attempts to convert them to group (2):
Of course some will remain in group (3).
The process by which an individual HEMS uses the central database to identify appliances in groups (1) and (2) is described in detail herein. Essentially the characteristics of the appliance are compared to known appliances for goodness of fit, in a similar manner to the clustering described above. Other clues, such as data collected at setup and responses from the HEMS user can also be used to improve probabilities. In order to do this, the central database will collect frequency data on the error rate of misidentification of appliances in the setup process and from user input (for example caused by mistyping the characters in a product code).
For appliances in groups (1) and (2) the central server will collect data on each appliance, grouped under appliance classes. This data will include data on rates of malfunction and deterioration. This condition monitoring data can support:
The level of clustering will depend on the degree of difference in phase space. Where appliances have identical model numbers but different components (for example different motors), then the instances will only be shown as separate where the differences create two clusters at the appliance level. Similarly where an appliance has more than one model number, but only one cluster, then the different model or build numbers will be shown as the same appliance. Having different plugs or different coloured panels does not change the essential characteristics of the appliance in terms of human behaviour, utility usage and work processes.
The individual HEMS can use the central server data to recognise appliances, either when the HEMS is first installed or when a new appliance is detected. Parameters of each appliance class are structured around the components and work processes known for that class of appliances, with the specifics of each appliance derived by class inheritance and populated with real data on the distribution of values of parameters.
Where a previously identified appliance either drifts or jumps to a statistically unusual value of a parameter, then a potential fault condition is flagged. Over time, feedback from maintenance technicians can be used to identify common fault conditions, so that they can be recognised from parameter values. This will be particularly valuable for incipient faults, where the pattern before failure is recognisable.
Where a new appliance is unrecognised but there is evidence that it should have been, then the system may also be able to make a fault diagnosis. For example a user buys a new washing machine. The HEMS recognises a new washing machine but not the model. The particular user maintains a high level of dialogue with the HEMS and provides the model number. The post hoc probability is now that it is recognisably that model with a known fault condition. The user can be told that it is faulty. This cannot be done without the model number because there is the obvious potential for a minor model upgrade to appear as an out of tolerance example of the older model. Appliance manufacturers may need to be disciplined in allocating build or model numbers or in providing appliance data in order to avoid fault reports from users.
In addition to characteristic parameters that allow the appliance to be recognised, the HEMS and central server also collect appliance usage data. In principle the HEMS also knows about the occupants and can correlate patterns of usage with occupant characteristics. This can add to the a priori probabilities for disambiguation but clearly has some consumer protection risks to using location data. The appliance usage data can be used to:
The HEMS also enables the integration of appliance usage data into the design and delivery of service products. We earlier gave the examples where faults found during service are fed back into the central database and incipient failures enable a preventative maintenance visit to be scheduled. A similar facility to that in modern cars will also be possible, where maintenance can be scheduled based on usage and not just time elapsed and all of this data can be fed into the design of the appliances and also service products like insurance and maintenance contracts.
With regard to creating the stored data representative of typical devices/appliances, the appliances, or the components of these appliances, can be described and written in a computer meta-language. Class inheritance can be used to reduce the task of creating data representing the appliances. An appliance consists of a set of work processes that employ component operations which use utilities in a set of time series patterns whose characteristics can be described by instancing classes in the meta language.
For the example of a dishwasher, as illustrated in
A specific model build could be derived by instancing the generic class of dishwasher published by the HEMS developer into a range of dishwashers with specific utility use characteristics (e.g. electric usage 54 and water usage 56) and then into a specific model with a defined set of programmes and components and finally a specific build with exact definitions of the components used, overwriting some of the default parameters in the components with specific values.
In a preferred version of this approach the manufacturer supplies appliances together with the distribution of parameters of utility using signatures of components and work processes of as manufactured appliances and aging functions over time. Manufacturers could also add value by measuring the signatures of each appliance as manufactured and supplying that with the appliance. For some components, such as light bulbs, there will be added value in deliberately using manufacturing processes to produce defined and well-distributed variations in signatures, so that each light bulb in a building can be distinguished through combinations of slight variations of power, start-up time etc., since the probability of having two bulbs with indistinguishable characteristics is a priori low enough to ignore. Even without this approach, the central database will contain information on component distributions that can be used to improve appliance recognition.
The meta language should be capable of instancing using formulae and conditional clauses, both in terms of compilation and operation. The language may represent both parametric and algorithmic relationships. The rules of the meta language provide a rich set of potential descriptions (so that complex operations can be described) and also extensibility (to allow for future component and process features not currently in existence). The top level of the class description describes the super classes of work flow, work process, component and the binding of work processes and components together that represents an appliance. There are a number of existing computer languages that could be used to implement such a set of descriptions.
Work flows represent a time series of work processes with individual occupant inputs that determine their characteristics: natural language description (where relevant), parameters of each work process and distribution of time between each step in the work flow. The appliance recognition module 2 does not allocate work flows to individual occupants, but other modules 6 of the HEMS 4 may tag instances of work flows as characteristic of an individual occupant or part of an unassigned pool.
In addition to occupant led work flows, there are also autonomous work flows, such as a refrigerator compressor switching on, a sprinkler system operating or night-time security lighting operating. These work flows can be attached to components that are sensors for hidden state variables (e.g. refrigerator internal temperature) or potentially estimable by the HEMS 4 (e.g. outside light levels or time of day).
Describing an appliance 7 at an appropriate level of detail will require considerable skill and experience. For example the exemplary dishwasher is likely to have a switch that interrupts the programme if the door is opened. In an embodiment, the HEMS 4 can detect and discriminate this event from normal operation. If the dishwasher restarts when the door is closed, then the corresponding signature will be described in the meta language. A washing machine or microwave that uses sensors to monitor its load will have a wider variation of work process parameters than one which follows a defined time sequence of component actions and parameter values.
Appliances 7 that can be operated by the HEMS 4, such as boilers and their associated components, can be configured at installation and the HEMS 4 will notify the appliance recognition module 2 of the current state of its control inputs. Also the HEMS 4 may be connected to smart appliances (not shown) which can identify themselves and their state to the HEMS 4. These appliances 7 can be treated in the same way as HEMS 4 controlled appliances 7, apart from the possibility of detecting user input.
Processing utility input data has foreground and background elements. Thus, the appliance recognition module 2 may be considered to comprise a foreground processing module and a background processing module. In an embodiment, in the foreground processing, the HEMS 4 constructs a hypothesis about the short term (typically e.g. 60 to 120 s, typically 100 s) expected forward Markov Chain of each measurement channel, based on the work processes hypothesized to be active at the current step. As the slowest measurement channel updates, the system state is checked against the hypothesised prediction. If this matches, then the appliance recognition module 2 captures and allocates the utility usage data across the work process, appliance and work flow hierarchy (
If the system state diverges from the forecast (i.e. outside tolerance), then the HEMS 4 first tests the hypothesis that a work process has been completed. In this case, the system updates as above, but it also transmits the usage data for that work process to the HEMS 4 (allocated to the specific appliance) for further use. Changes to appliances and any smart appliances controlled by the HEMS 4 are automatically incorporated into the forward chain forecast, to avoid unnecessary computation, but the usage data is captured.
Where the expected/hypothesised normal completion of a work process does not explain the actual current state of a utility or utility channel, the system enters a different loop that attempts to identify the cause of the deviation. The system starts to buffer incoming measurement channel data on signals 34, 36, 38, 40 for analysis. The first step is to search across all appliances 7 for potential user inputs that could explain the Markov Chain accumulating in the buffer (i.e. in the local storage unit 8). The second step is to search for autonomous changes that could explain the Markov Chain. From this reduced set of work processes, a search is carried out on the work flows that include these work processes to assign a most probable cause.
Potential causation hypotheses tested are:
All previously known work processes are, by definition, part of a work flow that includes at least that work process.
The appliance recognition module 2 maintains statistics on the previous use of each known component, work process, appliance and work flow. These statistics may, inter alia, include any one or more of:
As such, the a priori probabilities include exogenous factors such as time of day, time of year, daylight time, external temperature and hypotheses about the occupation state of the building based on other inputs and other factors for which a state estimation is possible and which are obviously potentially correlated with appliance usage patterns, either through autonomous means (such as daylight switches) or human factors (such as sleep or thermal comfort).
There may be more than one hypothesis of appliance usage that could fit observed data. Primary disambiguation of such alternative explanations can occur by examining the utility usage patterns of appliance components. Of note, water is important and useful in the disambiguation process since it is only utilised in some work flows and work processes, and then in specific and often predictable ways. If more than one explanation survives this “filter”, then the statistics referred to above are used to assign probabilities to the alternative explanations.
Reference to “other” appliances implies searching a complete list, for example, including re-pressurising the heating system or bleeding a radiator. Frequency distributions are used in this analysis according to their weighted explanatory power, as exemplified in
For example,
The exact detail of the probability weightings is a matter of experienced fine-tuning but the general principles are that statistics based on larger numbers of samples carry more weight, that distributions with less dispersion (multi-modal variance) carry more weight and that the aging statistics are used to check disambiguation as an alternative hypothesis, according to the example truth table shown below:
In this example, any one of components A, B or C could match the pattern of utility signals i.e. any of components A, B and C could be matched to recent data that has been obtained. Looking at the usage context statistics (“All data”), component A appears to be the most likely responsible component, however the recent usage pattern is less consistent with this and this usage is therefore flagged as ambiguous.
In the case where the component is recognised as a known component, there is a hypothesis of an unknown work process attached to the appliance. The foreground process can collect the data against the appliance, but it makes a record of the data sequence location in time as an instance of an unknown work process. It also creates a new work process against the appliance definition that contains the new utility usage pattern. The work process data capture continues on the assumption that activation of any components associated with this appliance within a period of time of e.g. up to two or three times the duration of known work processes of that appliance is part of this new work process.
In normal operation, the background process is launched when any of the following situations arise:
The background process has access to the entire history dataset and current status of the HEMS 4 at the point it is launched. This data is frozen, in the sense that it is not updated while the background process is running. This is achieved by taking a full copy of the current data and by using the last time step of that copy as the horizon of any review of historic data.
Whereas the foreground process limits its search to components, work processes, appliances and work flows that are already assumed to be present in the building, the background process has the tasks of dealing with ambiguity, updating and reviewing the component, work process, appliance and work flow data and managing on-going alignment between the appliance recognition module 2 and other HEMS modules 6.
The background module is first run as part of the engineer setup and installation of the HEMS 4. In this “setup mode” the HEMS 4:
Following setup, the appliance recognition module 2 will enter a period of learning or training. During this period it is gathering data in foreground mode but not attempting to identify devices/appliances 7. Noise calibration routines are performed to clean up the data, which is being written to the history file. The appliance recognition module 2 is only able to provide gross utility usage data to the HEMS 4, although it will be able to revisit this later, since all the data is stored. This training period should last long enough for sufficient information to be gathered on the work flows for identification of the patterns of appliance usage. To some extent this is a statistical test—if the appliance recognition module 2 is not able to come to sufficiently strong conclusions, then more time is required. For example, a month of continuous occupation of the building would be a reasonable period to gather data before attempting to carry out the first appliance identification as, within this time period, regular and pattern usage of various appliances should have occurred.
There are a number of known algorithmic approaches to recognising appliance activity from utility data. Aspects and embodiments of the present invention are distinguished from them by utilising the finite state analysis, and also the a priori probability analysis, and further by applying the concepts of work flows as a set of work processes and of using a shared database to set initial probability estimates. In addition, aspects and embodiments of the present invention are not attempting to identify what devices are present in a building from a state of pure ignorance. Not only does the method recognise that there is likely to be a refrigerator in most dwellings (unless all of the surrounding ones for some distance do not have them), it also has inputs from the installation engineer on major visible appliances, number of rooms and therefore likely number of lumieres etc.
The optimum solution will be a combination of algorithms which start from the a priori probabilities. Since there will be pragmatic trade-offs in any application of aspects and embodiments of this invention, not least between fidelity and cost, the most suitable approach for any application cannot be exactly determined in advance.
To further aid understanding, the HEMS 4 may be considered to be an experienced engineer analysing the data forensically, using a computer and a selection of mathematical algorithms to search large spaces efficiently using a combination of different approaches.
The very first step is to identify the patterns that the HEMS 4 already knows about from smart appliances and other appliances 7 connected to the HEMS 4. The utility usage patterns have the estimated signature of these appliances removed. This is not a trivial process; in outline it is described in
The next stage is to look for explanations of utility usage. As mentioned above, it is convenient to start with instances of water usage, since there are fewer of these than electricity uses. The stages of this are:
During normal foreground operation the appliance recognition module 2 is matching its stock of known components from the reference data to the detailed signals available from the measurement devices 10, 12, 14, 16, using the hierarchy of appliance work processes and occupant work flows (
The background process is started when required:
The processes described above will enable the ‘key’ energy signatures to be detected and analysed in order to identify one or more appliances through comparison with the expected energy signature profiles of a number of different appliances and models. These ‘key’ appliances will be washing machines, dishwashers, TVs, refrigerators, freezers, lights etc. This will leave a combination of energy signatures that are more difficult to distinguish, which may originate from smaller appliances such as device chargers, and appliances/devices that are on continuously contributing to the background signature such as burglar alarms, the HEMS 4 itself etc. Once the ‘key’ appliances have been identified or recognised, the remaining data can be analysed to identify the remaining appliances according to the same processes. The aim is to identify all appliances in the building. The identification of some appliances will be able to occur quickly, by comparison with the reference data and historical/typical usage data for the building/surrounding geographical area etc. Others may require monitoring over a longer time e.g. if an appliance is used infrequently.
For example, there may be 250 appliances/components in a house. The appliance recognition module 2/HEMS 4 aims to know what state they are in at a particular moment in time. This includes a hypothesis based on Bayesian probabilities. The most probable explanations are considered first, which will lead to a number of appliances being recognised. The remaining energy signatures are then analysed and compared with hypotheses with the aim of identifying the appliances and/or the state of those appliances. By enabling the most likely hypotheses to be searched first, this advantageously increases the chance of successful disambiguation and reduces computational requirements.
Aspects and embodiments of the invention advantageously provide for more comprehensive integration of information from sensors on utility flows into the dwelling and internal sensors to provide a better base dataset than has previously been possible. This enables understanding of patterns of occupancy within the building, of appliance and utility use, which aids consumers in managing their utilities more effectively.
Furthermore, unlike known systems, aspects and embodiments of the present invention incorporate patterns of human behaviour in using individual appliances, and combinations of appliances in recognising workflows like washing, cooking, bathing/showering etc., which facilitates appliance recognition.
An overview of the system context for a HEMS 4 in accordance with an embodiment of the present invention is illustrated in
Aspects and embodiments of the invention also employ disambiguation by construction and testing of hypotheses within and across many dwellings through sophisticated algorithms. Such processes have not been possible prior to now.
It will be appreciated by persons skilled in the art that various modifications may be made to the above embodiments without departing from the scope of the present invention as defined by the claims. For example, features from one embodiment may be mixed and matched with features from other embodiments.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1503042.2 | Feb 2015 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB2016/050460 | 2/24/2016 | WO | 00 |
