If you’ve had any involvement with SMETS2 at all – whether as manufacturer, supplier, systems integrator, or meter operator – you will have become accustomed to testing. And more testing. And then some more testing, just to be sure. The amount of testing increases seemingly exponentially the more parties are involved.

The bulk of this testing, of course, is to ensure security. And that’s all well and good, of course. But, as any software engineer will tell you, when the demands of security – or any set of rules, actually – get in the way of efficient working, shortcuts are taken.

As a systems integrator, our experience with the testing maze comes mainly from making commissioning calls from the field – in the form of an engineer’s handheld – through various DCC adaptors to the DCC itself. This has given us more than a taste of numerous environments: for initial comms testing; in using virtual meters; using live meters in the lab; and, finally, commissioning live meters on the customer wall.

And what has become abundantly obvious and frustrating in equal measure during testing, is that each of these different environments seem to require not only different security credentials but produce subtly different messages and errors in response to each process.

As a result, what works in one environment doesn’t always work in the next. Each test is almost like starting from scratch, especially in terms of the errors returned from the DCC. This raises a significant question about just how complicated connectivity has been made in the search for a not very well understood notion of security.

Are we protecting the integrity of the energy supply or are we really just adding layers of technical complexity that impacts the roll-out in an attempt to prevent a minuscule number of consumers fiddling their bills?

Graham Stewart

Systems Designer

Cloud KB Limited