The Darkness Lying in Wait for Smart Meters

Don’t worry, this isn’t another conspiracy theory article outlining the surveillance and mind control dangers posed by those dastardly smart meters that are gradually — very gradually — appearing in our homes.

This is about something far more serious.

Millions of second generation (SMETS2) smart meters have been installed. Each of those meters contains a small, ticking data timebomb that threatens to turn a smart meter into an expensive collection of plastic and metal.

And this threat is not as widely recognised as it should be.

Every smart meter delivered from the manufacturer comes with software installed that allows it to function and to communicate with the communications hub that sends its data back to the Data Communications Company (DCC) that gathers, among other things, readings and usage statistics. So far, so normal.

This key software is installed on the meters as firmware. Firmware is embedded into the hardware itself — hence its name — so it can control functionality more quickly and directly. And, as with all software, firmware needs to change over time as updates and patches are released by the manufacturer.

The reasons for firmware updates are many but the most important — especially in the eyes of the DCC — is for security purposes. The DCC is especially wary of software vulnerabilities. (We can’t have all the meters being switched off remotely on the back of some ransomware attack and, equally, the energy companies are not too keen on the idea of clever software hackers supplying fuel for free.) Keeping firmware up to date is therefore a key element of managing a smart meter portfolio.

There’s an added twist here. When the DCC determines the firmware for a meter needs to be updated, it sets a deadline for the changes to be applied. Fair enough. And what happens when the deadline hits and a meter is not updated? Simple: the meter goes dark. It hangs on the wall and refuses to accept or send any information. In other words, the meter drops off the energy supplier’s radar to all intents and purposes.

Who is responsible for maintaining firmware? You would think it would be the manufacturer. After all, they have to create the new firmware, test it, and then have it accepted by the DCC into its list of approved products. Or possibly the meter asset provider (MAP) that rents the meter to the supplier.

But no. It is the energy supplier itself — the company whose gas or electricity arrives at the smart meter — who needs to ensure the meter firmware is updated.

The supplier is making money from the energy consumption measured by the meter, so perhaps that makes sense. But the supplier then needs to know, not only what version of firmware a meter has installed, but the make and type of each meter. This is not an easy proposition when customers switch between suppliers increasingly frequently and, let’s face it, the quality of industry data leaves a lot to be desired.

What, then, are the options available to the supplier?

That was a trick question. There are no options, plural. There is only one sequence of actions to follow:

1. Query every meter point supplied for a list of smart devices

2. Compare the firmware version at those devices with the DCC’s recommended version

3. Update the firmware to the recommended version before the old firmware’s expiry date

4. Repeat

The ‘repeat’ is essential because firmware updates don’t happen to a regular timetable. (Firmware does have a natural lifespan, but it is highly unlikely that a firmware version will remain stable and require no updates during that time. If the firmware does, by some miracle approach the end of its natural life — certification — this will still need to be updated. Needless to say, the firmware has a much shorter projected life than the meters in which it resides.)

I’m not even going to talk about some of the problems involved in updating the firmware for many thousands of devices over a short space of time.

Oh, OK, I will. Here are just two I can think of:

• Size of firmware versus cache on communication hub to which firmware is sent
• Length of time it takes to send data to large numbers of devices

(It is worth noting here that firmware is updated remotely, via the DCC. Updating each meter through an engineer’s visit would, of course, be financially unviable.)

All of the above points to the firmware issue having the potential to become an existential threat to the very real benefits smart meters are intended to bring.

Until a technical solution is devised that allows for quick remote updates at devices, the only answer to the firmware problem is better management of the data and surrounding processes.

And better management begins with a clear view of what devices are in a supplier’s portfolio and if and when the firmware at those devices needs to be updated. An energy supplier has two choices here:

1. Build and maintain a reporting function that produces alerts when firmware updates are needed

2. Contract with a dynamic and innovative systems provider to generate the required reports and free up in-house resource

I may be biased, but option two looks a winner to me.

kevin@cloudkb.co.uk