Quote from Ofgem Guidance:
We are proposing the principle that consumers should be able to choose how their consumption data is used and by whom, except where the data is required to fulfill regulated duties. This principle reflects that being considered by energy regulatory bodies across Europe it is this principle upon which we intend to build our approach to privacy issues.
To help consumers understand better how smart metering data will be used we are proposing to work with stakeholders to develop a privacy charter. Such an approach is seen as good practice by the Information Commissioner's Office (ICO).
The Government is committed to every home in Great Britain having smart energy meters , and consequently empowering people to manage their energy consumption.
- Personal data must be fairly and lawfully processed
- Personal data must be obtained only for specified and lawful purposes, and must not be further processed in a manner which is incompatible with that purpose
- Personal data must be adequate, relevant and not excessive in relation to the purpose for which it is processed
- Personal data must be accurate and, where necessary, kept up to date
- Personal data processed for any purpose must not be kept for longer than is necessary for that purpose
- Personal data must be processed in accordance with the person's rights under the DPA
- Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data; and
- Personal data must not be transferred outside the European Economic Area unless that country or territory ensures an adequate level of protection in relation to the processing of personal data.
Something we are wrestling more and more with is data protection.
With a system having the ability to send out second by second data, the question becomes do you want it to in reality?
It would be nice if as an industry we could arrive at a standardised form to cover data use, based on the latest legal requirements – to protect everyone.
Only a very tiny amount of data is really useful:
• error codes (such a pressure in a central heating system dropping too low) • energy consumption (taken care of by metering contracts) • diversity data - hot water use • operational data for first month or so to check performance (commissioning check) • differential pressure - only plantroom needs to know this for pump control
The easy approach is to get users to agree (to sign off that their data is going to be used for other reasons) and appears to be the most common approach.
My problem with this approach is that users have no idea what data from a hot water systems can betray. One can quickly learn a user’s habits& patterns, and work out when to rob the place. If they knew, which they will eventually I imagine, then they may not be keen to sign up in the first place. And the law is on their side.
Data can be anonymised – removing any references to serial numbers etc that enable data to be traced to any one property. That’s ok for stuff like diversity data or differential pressure as the location is irrelevant to the use. Again there is a problem – assuming one unit has a DHW setpoint different to others then it will stand out in such a data feed as much as a serial number.
My thinking is we need to treat any data sent out automatically as public – it has the potential to end up in a 3rd parties hands.
So, the thinking is to remove from anonymised data all settings, and just leave the data needed. So for a public diversity feed for example one may only include:
- DHW flow rate
- DHW temperature
- Primary flow temperature
- Primary return temperature
- Primary DP
- Primary flow rate
- A timestamp
This much I believe can be done without a user’s consent, providing the data is mixed up with other feeds it’s impossible to tell where it came from. The real value in this data is hidden – it’s used by a plantroom for managing loads, can be used by a client to confirm VWART performance, or diversity data can be used in future designs.
Anything else would require consent.
Then one needs to come up with a simple system whereby users can protect their data but it can be made available when it helps.
SCENARIO 1 – KNOWN PROBLEM
For example, when there is an error (central heating pressure dropping because of a leak) it can go a few ways:
- Nothing – pressure drops to point where system fails and an emergency call-out
- error code is automatically sent to the managing agent, so they can arrange a service call-out before an emergency arises (requires data agreement for data to go to X when Y happens)
This much would want the user to agree that “under fault conditions your system may raise an alert to remote agents”. My better half is paranoid about data she said she would sign off on is. Automatic is better as its easy – user is safe that their daily patters are not ending up in a database somewhere, but any problems will be handled automatically.
This gives you the features most want I believe, so only data that requires a response by engineers is sent out. (kind of the point of it all).
SCENARIO 2 – UNKNOWN PROBLEM
This covers anything else, such as a user claiming hot water is not hot enough for them, or hot water is intermittent because of a central pump problem. A system will not be able to raise a clear error message on its own – the user needs to ask for help.
The normal response is then to send an engineers and discuss the problems, and adjust settings or educate the user etc. This is probably the arena where most engineer time is wasted – there may be a number of call-outs until the root cause of the issue is identified.
The solution that works is for the user to indicate there is an use, then for an engineer to look at the data remotely, diagnose any problems, then either fix remotely or call the user to arrange the remedy. (again I could get agreement on this if it were our house).
The difficult bit is how do you give someone (time limited) remote access to data from your property?
Internet routers have a button you can press to enable access, but HIUs or hot water cylinders don’t. Hot water and heating systems do have taps however, so it is proposed that a tap can be used by a user to indicate both a problem, and give permission for data to be sent out for diagnosis.
Turning a tap on and off repeatedly is something that never happens in reality more than a couple of times. To go on/off five times in a row (no gaps longer than 10 seconds) is a pattern that anyone can understand, but would never come up accidentally. It also ties permission to the user directly, better than any password system can. And it takes no management, so if someone moves out, they simply lose access to the tap (and data).
Therefore it is proposed that when a system detects a tap has been cycled 5 times it initiates the sending and storage of performance data for 48 hours. This is enough data for any engineer to see what’s going on. Remote commissioning can also be turned on this way.
So, if I want the temperatures cranked up – I like hot water really hot and systems have been commissioned lower than I like – I would then phone up my managing agent to ask for hotter water. In turn they ask me to activate my tap 5 times (thereby turning on remote access for 24hrs), so they can view the data to confirm what its set to, and remotely turn it up a bit. A day later the agent loses their feed, and its back to a silent system.
- The bulk of all data made available is simply ignored and never stored or transmitted.
- Only very limited (need-to-know) anonymised data will be sent out as part of a systems normal operation (to avoid eavesdropping)
- Error data is sent out when an error occurs that will require intervention.
- Performance data is sent out continuously for 48 hours following user activation (via tap).
- Remote commissioning is enabled for 24 hours following user activation (via tap)