By Bruce Rowse *

There is strong demand for metering solutions that incorporate cloud data collection. This is enabled by reductions in the cost of electricity metering and sensing technologies, advances in communication technologies, the development of the Internet of Things (IoT) as a lower cost alternative to traditionally vertically integrated metering solutions, the move to smart metering and interval sub-metering.

Having meter data available in the cloud provides several advantages for measurement and verification (M&V). Data is available to any authorized user anywhere, without having to visit the site. Access to the data can be shared relatively easy. The data can be easily managed, for example data can be backed up automatically. Large cloud data sets covering multiple facilities can be used for the purposes of evaluation the effectiveness of energy efficiency programs. Faults can be detected quickly.

For M&V practitioners, an awareness of the approaches and challenges in the collection and access of meter data in the cloud can aid in the selection of a suitable metering data collection system.

This paper describes the many different approaches with which data can be collected from a meter and transferred to the cloud. It introduces to M&V practitioners the widely used Open System Interconnection (OSI) model of computer networks for conceptualising the functions of the software and hardware used to achieve this.

It then looks at the challenges, with a particular focus on security, but also considering complexity, lifetime and cost.

Advantages of cloud-based metering for measurement and verification

A key advantage of cloud-based metering is the easy availability of this data to anyone with the credentials to access this data. An example of this comes from my home state of Victoria, Australia, where smart meters have been deployed and I can access metering data for my home from an online portal. After replacing my home gas heating with a reverse cycle heat pump, I was able to roughly identify when the heat pump was running, how much additional electricity I was using, and determine the additional electricity cost.

Furthermore, I can go to the portal at any time, and see how much energy I used in the previous hour. This can be useful if I am away from home and I want to see if the heating has been turned off! Or it could be used to verify operation of my rooftop solar PV system.

Figure 1

Electricity data from a utility portal. The daily graph was generated at 2:19pm, and shows energy used up to the most recent hour. Note on graphs: Negative consumption is due to the net-metered rooftop solar PV system.

Utilities can use cloud-connected meters to monitor and detect problems in the electrical network such as open neutral and stray voltages.[1] For M&V practitioners, collecting meter data about voltages can also potentially be used to identify faults with equipment that is being sub-metered, and as a way of verifying persistency of operation of the Energy Conservation Measure (ECM).

Cloud based data can be held for long periods which may be of use when local records no longer exist. For M&V, archived interval data can be used to investigate outliers in baseline regression models of energy use. Large data sets of cloud-based data can be used to evaluate utility-based energy efficiency programs, as is being done in some parts of the USA[2].

Approaches to data collection from remote meters

Taking data from a device, such as an energy meter, and transferring it to the cloud, is a complex process.

What is now known as the IoT, (which would include energy meters with data connectivity) has gradually emerged over time, and across many industries. As a result, there are many communication protocols, both legacy and emerging, that are used to enable things, such as meters, to communicate with servers.

Widely used protocols include HTTPS, XMPP, CoAP, MQTT, AMQP, UDP, TCP, IPv5, 6LoWPAN, RPL, IEEE 802.15.4, Wifi (802.11 a/b/g/n), Ethernet (802.3), GSM, CDMA, LTE, demonstrating that there are many possible approaches that can be taken with respect to connecting meters to the cloud.

For example, at the network access and physical layer, metering systems exist that use:

• IEEE 802.15.4g, otherwise known as Wi-SUN (Smart Utility Network) mesh networks
• 3G and 4G phone networks
• Wifi
• Modbus, and other field buses (discussed below)
• Ethernet
• Power Line Carrier (PLC)

Challenges

The key challenge with the use of cloud-based metering solutions is security. Other challenges include the complexity of these systems (which is often hidden), reliability, ensuring a long lifetime in face of rapid technological change, and the ongoing costs of these systems.

Security

Some of the security issues that may arise include:

• Falsification of data. This is of critical important for M&V.
• Taking over a device to launch a denial of service attack. A denial of service attack occurs when a server is bombarded by so much traffic that it can no longer serve the genuine users.
• Theft of data. For example, as electricity meter data can provide an indication as to the occupancy status of a building, such data could be used by burglars to time a theft.
• Phishing emails. For meters with embedded email servers, there is a risk that these could be used to send spam email.[3]

The growth of IoT is creating a vast number of “things”, including meters. Cheruvu S. et al propose an internet of things pyramid[4], as shown in the diagram below, where the number of items in each layer increases exponentially. Intel predicts that by 2020 there will be 200 billion “objects” an object being anything that has a microcontroller of some kind, such as an energy meter. They identify that this bottom layer represents the largest attack surface for hackers.

Figure 2

Internet of Things Pyramid. From Demystifying Internet of Things Security, Cheruvu S. et. al.

Cheruvu. S., et al also identify that the computing resources required to ensure the security of devices is large for the low powered IoT objects at the 5^th layer in the IoT pyramid. They state:

“Our estimates suggest that as much as 60% of a constrained environment computer could be focused on performing security-related computation, leaving 40% for application-specific computing. In other words, the “tinification” (the process of removing unused functionality not needed by purpose-built embedded systems) of an application to fit into constrained environments results in the need to preserve more of the security functionality than the non-security functionality. This leads business decision makers to question the viability of profits in constrained environments. Often these trade-off decisions lead to justification for weaker security, lack of firmware update capability, and no support for hardware root-of-trust architectures.”[5]

For example, the Arduino Uno is seen by many electronic hobbyists as a potential low-cost MCU for a home-built IoT device. However, in order to meet AWS security requirements, which require the use of an X.509 certificate with an asymmetric key, an MCU needs to be approximately ten times more powerful than an Arduino Uno.[6]

The large number of smart meters already deployed and about to be deployed around the world (predicted to reach 1.2b by 2024[7]) has and will continue to attract the interest of hackers. In March 2019 the UK’s Institution of Engineering and Technology identified that the search term “how to hack your energy meter” on youtube came up with nearly 100,000 videos.[8]

Implementing appropriate meter to cloud security involves four areas of focus:[9]

1. Protecting the device
2. Protecting user identity
3. Protecting the data
4. Managing the security at runtime

In the USA the National Institute of Standards and Technology has developed a draft guide to security for IoT devices.[10]

Complexity

As outlined earlier there are many, many ways in which data can be transferred.[11] IEEE provides a “partial listing” of IoT related standards, with a mere 80 standards in this listing![12]

In IT nomenclature, a “full stack” developer is one who is seen as having a good understanding of all the layers in the OSI model and can deliver projects that span the model. However even an experienced full stack developer is unlikely to be knowledgeable about all the many protocols and standards that can be selected from when developing a system that takes meter data to the cloud.

For energy engineers, who by and large are not from an IT background, the complexity is overwhelming. IoT frameworks are one way of managing this complexity. As IoT matures, one hopes that tools such as frameworks become effective in managing IoT complexity, whilst ensuring the security, integrity and reliability of meter to cloud systems.

Reliability

Reliability of a cloud-based metering system can reduced by a range of factors, depending on the architecture of the system.

Three common issues are:

• For meters with pulse outputs, loss of pulse counts can create untraceable errors. Using meters with inbuilt registers, and where the cumulative energy register value is transferred to the cloud or used to check data before sending to the cloud, is an effective way of overcoming this problem.
• Incorrect configuration of communication parameters. For example, with meters with Modbus connectivity, data may be truncated if the device interfacing with the meter doesn’t read the correct number of bytes from each meter register. Commissioning checks can overcome this.
• Loss of connectivity. This is particularly the case for wi-fi based meters which are relying on the site’s wi-fi network. The meter may lose connectivity if network settings are changed or network equipment is upgraded. To minimize the chances of this the network needs to be well documented and the system administrator aware of the device.

Lifetime

Metering installations are generally expected to have a long life, usually in excess of ten years. In the world of IT, ten years is a long time! Ten years ago, the IoT as we now know it didn’t really exist. If you are reading this paper on a computer, tablet, or phone, it won’t be the one you had ten years ago.

Metering systems based on CDMA, GPRS or 3G networks most likely aren’t working today because around the world those wireless phone spectrums have simply been switched off. Any metering system that transfers to the cloud needs to consider the likely lifetime of the solution being deployed and technological changes that may occur in that time.

Quantum computing, for example, has the ability to be able to crack asymmetric keys that are now commonly used to protect data as it is transferred from a device to the cloud.[13] In 2020 quantum computers are not readily available. But will that be the case in 2030?

Security requirements are likely to also to continue to expand, likely requiring more computing resources. This clearly has implications for the installation of long-life metering installations, and upgrade pathways, whether they involve over-the-wire firmware upgrades (will the MCU installed today be powerful enough to take on future upgrades), or physical upgrades (how much time is required and what will the cost be?).

Ongoing costs

The many advantages offered by cloud connected meters come at an ongoing cost. There are costs associated with transferring data across networks, storing data, undertaking routine maintenance (including monitoring for faults/suspicious activity), and potentially over the life of the metering installation undertaking physical upgrades of the network facing MCU for security purposes. There are also the costs associated dealing with any faults.

These costs are not just financial. There is the ongoing responsibility associated with the privacy of the data collected. Energy data in particular can be used to reveal sensitive information (such as hours of occupancy).

Finally, the environmental cost of cloud-connected meters is a consideration. From an energy perspective this involves looking at the trade-off between choosing, on the one hand, what to meter with a cloud connection, the data logging frequency, frequency of data collection and, on the other hand the energy savings that are enabled by it. Another energy consideration is archiving procedures, and the age at which data is put into “deep freeze” archiving, so as to reduce the energy used to store the data.

Techniques for managing these costs can include lifecycle assessment of costs in the planning stage (the more expensive MCU may be cheaper in the long run), consideration of cradle-to-grave environmental impacts, and ensuring that there is an appropriate strategy in place for managing security over the lifetime of the metering installation.

Conclusion

Connecting meters to the cloud provides many benefits for energy management and can make M&V much easier than it would be otherwise. There are a large number of protocols than can be used when connecting a meter to the cloud, and doing so in a way which is secure, ensures data integrity, and is reliable involves navigating through a complex environment. Challenges involved include managing always evolving security requirements, dealing with the complexity of IoT, ensuring that the system providing the connectivity can last as long as the meter, and managing ongoing costs. Thorough life-cycle planning and recognition that there will be ongoing costs beyond data hosting can help ensure reliable, secure, long-lasting metering installations.

REFERENCES

[1] https://www.iothub.com.au/news/how-united-energy-leverages-its-smart-meter-network-464264

[2] For example, as done in Oregon. https://www.recurve.com/solutions/quantify

[3] https://www.corero.com/blog/537-whats-in-that-refrigeratorfish-or-phish.html

[4] Cheruvu, Sunil et al.

[5] Cheruvu, Sunil et al. Kindle Location 740.

[6] Based on experimentation done by the author using AWS provided security credentials.

[7] https://www.woodmac.com/news/editorial/global-smart-meter-total-h1-2019/

[8] https://eandt.theiet.org/content/articles/2019/03/youtube-videos-showing-how-to-tamper-with-energy-meters/

[9] Cheruvu, Sunil et al. Kindle Location 2696.

[10] https://www.nist.gov/news-events/news/2019/08/nist-releases-draft-security-feature-recommendations-iot-devices

[11] This article introduces popular protocols: https://developer.ibm.com/articles/iot-lp101-connectivity-network-protocols/. Additional protocols are covered here: https://www.postscapes.com/internet-of-things-protocols/

[12] https://standards.ieee.org/initiatives/iot/stds.html

[13] Cheruvu, Sunil et al. Kindle Locations 1425.

(*) Bruce Rowse is a consultant with 8020Green and is based in Australia. Bruce is the chairman of EVO's Extended Training Committee and an EVO L4 accredited instructor.