From device to the cloud: approaches and challenges in getting HVAC&R data from remote devices

By Bruce Rowse, M.AIRAH

Introduction

There is strong demand for HVAC&R monitoring and metering solutions that incorporate cloud data collection and real-time or near-real-time cloud-based control. This is enabled by reductions in the cost of sensors and meters, advances in communication technologies, the development of the Internet of Things (IoT) as a lower-cost alternative to traditionally vertically integrated systems, and the move to more frequent data collection. 

Having data about device operation available in the cloud provides several advantages for the operation and maintenance of HVAC&R equipment. Faults can be detected quickly, and alerts sent to anyone, anywhere, automatically. Where metering is installed energy usage and efficiency can be monitored and controlled remotely. Data from multiple sources can be combined and analysed, including using machine learning methods, to enable prediction of future performance. 

As the management of electrical demand becomes of increasing importance to ensuring a reliable electricity supply, real-time data sets can be combined with controls to ensure grid reliability, or to manage electricity costs. 

For HVAC&R practitioners, an awareness of the approaches and challenges in the collection and transfer of data from device to cloud and back again can aid in the selection of a suitable data collection and communication systems. 

This paper describes the many different approaches with which data can be collected from a device and transferred to the cloud. It introduces to HVAC&R 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. 

While the paper is focused on transfer of data from device to the cloud, many of the same principles apply to the transfer of control signals from the cloud to a device. The paper also has a focus on electricity metering, however the same principles would also apply to other sensors and devices that may be incorporated into HVAC&R equipment.

Advantages of cloud-based device monitoring

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, where smart meters have been deployed and I can access metering data for my home from an online portal provided by the electricity distribution business servicing my area. 

After replacing my home gas heating with a reverse-cycle heat pump, I was able to 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 9am, 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 use cloud-connected meters to monitor and detect problems in the electrical network such as open neutral and stray voltages.[1]

HVAC&R practitioners will be familiar with the emergence over the past five to 10 years of much greater cloud connectivity of ever-smaller devices. Smart thermostats, air conditioners with in-built wifi connectivity, and even domestic fridges that send data to the cloud are some examples. Some of the benefits include the management of electricity consumption and demand[2], reduced food spoilage in the cold chain[3] and improved maintenance and reliability of complex HVAC systems[4].

Cloud-based data can be held for long periods which may be of use when local records no longer exist. For energy management such data can be useful to track equipment performance over time (e.g., gradual decline in chiller efficiency) and historical data sets can be useful in the training of machine learning algorithms that can be used for predictive purposes, such as predictive maintenance, or to aid in the measurement and verification of energy savings.

Approaches to data collection from remote devices

Taking data from a device, such as an air conditioner, and transferring it to the cloud, is a complex process which can be done following many different protocols. 

To understand the approaches to data transfer available firstly the concept of understanding the networking of computers using the Open System Interconnection (OSI) layer model is described. Then, with reference to these layers, the many possible protocols which can be used when data is transferred is discussed. Finally, four approaches to data transfer are explored.

The OSI layer concept

The OSI model is a conceptual model [5] that describes the functions of a networking system.

It uses layers to describe components of a network that interact in a hierarchical and sequential way, with each layer usually only interfacing with the layers above and below it.

The OSI model can be used to trace how data is transferred in a network. It is a logical representation of how network systems communicate (or how they are supposed to communicate).

The OSI model gives a structure to networking, it enables product developers to just focus on one layer (rather than the full stack), reducing complexity and speeding development and evolution.

The OSI model is comprised of seven layers, as illustrated and briefly described below, staring with layer 7, the application layer, which is closest to the end user, and going all the way down to the physical layer, i.e., the voltages and their pattern going through a transmission medium.

In communication between two users on a network, a message from the sender goes down vertically through the layers, is then transferred through the physical layer to an intermediate node, is processed through the bottom three layers at each intermediate node, continues hopping through the physical layer between intermediate notes, until it reaches the final destination, where it then goes up vertically through the layers to the recipient.

Figure 2. The OSI model, showing how messages are transferred between users across a network. Adapted from https://slideplayer.com/slide/5178864  

Layer 7, Application. The layer that is seen by users and interact with users. For example, a web browser is an example of a layer 7 application.

Layer 6, Presentation. This layer is responsible for the formatting of the data, and involves encoding, encryption and compression. For example, when you send a pdf document, the presentation layer encodes it so that it can be sent, and for the person receiving it, the presentation layer decodes it into the pdf format. ASCII for example in an encoding format.

Layer 5, Session. This establishes, maintains and terminates the session between two computers that are communicating with each other. For example, when you visit a website your computer has to create a session with that site’s web server.

Layer 4, Transport. This decides how much information to be sent and received at a time. It also provides processes for message delivery and error recovery, so that a message just doesn’t go from point to point, but goes through all the different points connecting a message end to end. The TCP protocol (part of TCP-IP) operates at the transport level.

Layer 3, Network. This moves packets of data from source to data and provides addressing and inter-networking. A router operates at this level. An IP address is at the network level.

Layer 2, Data link. This takes bits of data and organises it into frames, ensuring delivery “point to point”, and redelivery if necessary. It’s the layer a network switch operates at. A medium access control (MAC) address resides in this layer.

Layer 1, Physical layer. This represents the medium and physical characteristics through which data is transferred. It includes the formatting of the message. E.g., address, message type, information. Using a checksum algorithm, it can also be used to detect and report errors in a message (but not fix them). It includes cables, radio frequency links, and other physical components.

The TCP/IP model, which underpins the internet, and with four layers, is a simplified implementation of the OSI model as shown in the diagram below.

Figure 3. OSI model and how it matches to the TCP/IP model.

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 energy meters or thermostats, to communicate with servers. 

Several of the common IoT protocols and how they match to the TCP/IP layers are shown in the diagram below. [6]

Figure 4. Mapping of widely used IoT protocols to the TCP/IP model. Adapted from  https://developer.ibm.com/articles/iot-lp101-connectivity-network-protocols/

It’s beyond the scope of this paper (and the author’s knowledge) to provide a detailed description of all of these protocols and their relative advantages and disadvantages.[7]

However, it can be seen that there are many possible approaches that can be taken with respect to connecting devices to the cloud.

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

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

Other machine-to-machine networks include LoRa, Narrow Band IoT and Sigfox.

Legacy systems comprised of embedded networks that have been used to connect meters to computers that displayed meter data, such as in a building management system (BMS) and in supervisory control and data acquisition (SCADA) systems, use process automation protocols, also known as fieldbuses. Some of the common fieldbus protocols include Modbus, Profibus, BACnet, LonTalk, among others.

The connection of fieldbus protocols to internet protocols, enabling true cloud-based access to devices such as meters, in some ways has represented a “cultural” clash, which has added to the complexity with which data from the legacy fieldbus-type metering systems is transferred to the cloud.

Fieldbus systems are generally highly vertically integrated and proprietary systems, and have prioritised data availability and integrity of data above confidentiality.

The IoT, emerging from the IT culture of the internet, is one based on open standards and inter-operability, and with a stronger focus on security, with confidentiality prioritised above integrity and availability. [8]

Examples of approaches for connection from device to the cloud

There are many ways in which devices can be connected to the cloud. Four examples of approaches are described below, for electricity metering, to illustrate, at a small scale, the diversity of ways in which connectivity can be achieved: 

1. Legacy sub-metering metering system with an on-site server
2. Utility automated meter reading (AMR)
3. Hypothetical low-cost open IoT meter
4. Meter as a web server

Legacy metering system 

A legacy metering system can typically be found as one of the legacy offerings from the long-established providers of BMS and SCADA systems. 

Such systems have a local network and local server, hosting a database where data is stored. Cloud-based access is possible through a firewall and virtual private network (VPN) connected to the local server.

Figure 5. An electricity meter fitted with an IEEE 802.15.4g mesh radio.

Utility Automated Meter Reading

Utilities are increasingly expanding the coverage of their AMR systems. 

In Victoria a smart meter rollout has meant that all electricity users have AMR meters. 

In metropolitan areas these meters connect via a IEEE 802.15.4g (Wi-SUN) mesh radio network. Between 2,000 to 4,500 meters on the radio mesh connect to a single gateway. [9]

Hypothetical “open” IoT meter

The development of platform cloud services for IoT, such as Amazon Web Services (AWS) IoT, Microsoft Azure’s IoT hub and Google cloud IoT make it possible for product developers to provide meter-to-cloud solutions at low up-front equipment costs by renting reliable, secure cloud services. These service providers take security very seriously, and their IOT platforms require that the devices connected comply with their security standards. 

Unlicensed wireless spectrums with effective ranges larger than WiFi, such as Wi-SUN and LoRa, mean that sub-metering solutions can be deployed in a building or factory with a single ethernet or 3G/4G gateway. 

Many meters (and sensors more broadly) come with Modbus interfaces. This includes electricity meters, gas meters, water meters, thermal meters, etc. A small micro-controller unit (MCU) can be used to interface the meter with a wireless radio device that sends the meter data to a gateway and then to the cloud. More powerful MCUs can also provide edge computing services. Several meters can be daisy-chained along a single Modbus cable, for example multiple electricity meters at a distribution board. The MCU should be powerful enough to enable a robust security system to run on it. 

Alternatively, an MCU may be incorporated into each meter’s individual meter housing. 

The diagram below shows such a system, incorporating multiple devices.

Figure 6. Configuration of a hypothetical IoT metering system.

Meter as a webserver 

This is a meter with an embedded MCU containing a webserver that hosts a website, and storage media. On a local network it would be accessed by its IP address. Cloud-based access could be through a virtual private network (VPN).

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 reliable and secure operation. For utilities, who don’t want their smart meters hacked into by energy users trying to reduce their bill, data security is essential to protect revenue.
• 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. A distributed denial-of-service (DDOS) attack happens when many devices send traffic to one server. In 2016 the then largest ever DDOS attack came from insecure IoT devices infected with the Mirai virus. [10]
• Taking remote control with malicious intent. For example, to turn off server room cooling, with the intent of shutting down computing services.
• 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 devices with embedded email servers, there is a risk that these could be used to send spam email. [11]

For a more comprehensive list of the many types of security threats associated with IoT refer to Ahmed, AW, Khan O.A., Ahmed M.M. and Shah M.A, A Comprehensive Analysis on the Security Threats and their Countermeasures of IoT.[12]

The growth of IoT is creating a vast number of “things”, including meters, with more than 30 billion devices to be connected by 2025[13]. Cheruvu S. et al propose an internet of things pyramid[14], as shown in the diagram below, where the number of items in each layer increases exponentially. Intel identify that this bottom layer represents the largest attack surface for hackers.

Figure 7. Internet of Things Pyramid. Adapted 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 bottom layer in their IoT pyramid. They state:

“Our estimates suggest that as much as 60 per cent of a constrained environment computer could be focused on performing security-related computation, leaving 40 per cent 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.” [15]

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 10 times more powerful than an Arduino Uno.[16]

With reference to the OSI model and TCP/IP models discussed earlier, each of the many potential protocols at each layer comes with its own level of security.

As an example, consider the legacy fieldbus protocol, Modbus.

Modbus has no encryption and the only “security” it contains is a check-sum algorithm. The check-sum is a value transmitted with each packet, and is a number than is created by applying an algorithm to all the previous values. A simple algorithm would be adding them all together. When the data is received, the check-sum is recreated to see if it matches the check-sum transmitted with the data. Any error indicates a problem with the transmission of the data.

With reference to figure 6 above, someone with malicious intent could initiate a man-in-the-middle attack between the device and the MCU to falsify device information. The checksum included in a Modbus packet only represents a minor obstacle into fooling the MCU that the meter readings are higher or lower than they are in reality. To initiate such an attack, however, would require physical access to the cable connecting the meter to the MCU.

The large number of smart meters already deployed and about to be deployed around the world (predicted to reach 1.2b by 2024[17]) has attracted, 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.[18]

As nations increasingly use hacking to seek advantage over other nations, and in some cases as acts of cyber warfare[19], insecure cloud-connected HVAC&R devices open up the potential for disruptions to the food chain, the provision of comfort (which could be life-saving on days of extreme weather), and other services enabled by cooling, heating and refrigeration.

Implementing appropriate device to cloud security involves four areas of focus:[20]

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

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

Complexity

The earlier discussion on the OSI and range of IoT protocols illustrates the complexity associated with metering systems that deliver data to the cloud. There are many, many ways in which data can be transferred. [22]

IEEE provides a “partial listing” of IoT related standards, with a mere 80 standards in this listing! [23]

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 device data to the cloud.

For HVAC practitioners, who by and large are not from an IT background, the complexity is overwhelming.

IoT frameworks are one way of managing this complexity. They can do this by “creating an abstraction of the IoT device networks that hides much of the underlying complexity while exposing data, interfaces, and functions that facilitate interoperation. All it should take to develop an IoT application is to create an application in a high-level language … that utilises framework APIs. The framework provides a semantically rich description of IoT nodes, objects, and interactions that allow IoT network designers to focus only on node interaction semantics rather than on the details of connectivity.” [24]

As IoT matures, one hopes that tools such as frameworks provide a seamless and effective way of managing IoT complexity, while ensuring the security, integrity and reliability of meter-to-cloud systems.

Reliability 

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

Three common issues are: 

• For devices with pulse outputs – typically energy meters ­– 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. Additionally, as insurance against loss of connectivity, data could be stored on the device, with the device configured to “gap-up” data back to the cloude when connection is restored.

Lifetime

Most HVAC&R equipment is generally expected to have a long life, usually in excess of 10 years, and some equipment for as long as 30 years.

In the world of IT, 10 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 10 years ago, and may not even be the one you had three years ago.

Phone spectrums that have been commonly used to enable device connectivity also have a shelf life. Device monitoring and control systems that relied on CDMA, GPRS or 2G networks aren’t working today unless they have been upgraded, because around the world those wireless phone spectrums have simply been switched off. The 3G network in Australia will be turned off in 2024. Will the 4G network still be around in 10 to 15 years?

Any system that transfers to or from the cloud needs to consider the likely lifetime of the solution being deployed and technological changes that may occur in that time.

This is important to consider when it comes to security.

Computers have evolved more or less in accordance with Moore’s law – coined by Gordon Moore of Intel in 1965 – that the number of transistors in an integrated circuit doubles roughly every two years. Although Moore’s law may be reaching its limits with respect to hardware, there still continues to be rapid evolution in computer systems as a whole. Unfortunately, security requirements also continue to evolve, perhaps also in accordance with Moore’s law, requiring more computing resources over 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.[25] In 2022 quantum computers are not readily available. But will that be the case in 10 years’ time?

This clearly has implications for the embedding of communications interfaces in devices, 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? And if not, how much time and money should be budgeted for hardware upgrades?

Ongoing costs 

The many advantages offered by cloud-connected devices 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 device undertaking physical upgrades of the network-facing MCU for security purposes. There are also the costs associated dealing with any faults. There is then the cost of monitoring technological changes and knowing when you should be taking pre-emptive action to protect against security threats that didn’t exist when the device was installed. 

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. Where IoT devices are deployed for energy efficiency purposes, this involves looking at the trade-off between choosing, on the one hand, what data should be sent to the cloud connection, the frequency of data collection and the energy savings that this enables, and comparing this with the cost and energy use associated with device operation, data transfer, storage and network access. Whilst power usage of any one device is small, over billions of devices the power usage is considerable. 

The use of resources to create the necessary hardware, and eventual e-waste, are also environmental considerations; not just of the devices themselves, but also the server farms that are used for storing and processing data. 

Techniques for managing all of these costs can include life-cycle 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 devices to the cloud provides many potential HVAC&R benefits, including enabling energy savings and improved reliability. There are a large number of protocols than can be used when connecting a device to the cloud, and doing so in a way which is secure, ensures data integrity, and is reliable involves navigating through a complex environment. IoT frameworks can simplify this complexity. 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 device, 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 installations.

References

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

[2] Aarish C., Jones, M., Smart Thermostats and the Triple bottom Line, 2016, American Council for an Energy Efficient Economy conference proceedings. https://www.aceee.org/files/proceedings/2016/data/papers/6_953.pdf

[3] Jutsen J., Hutton C., Pears A., Food Cold Chain Optimisation – improving energy productivity using real time food condition monitoring through the chain, 2017, Australian Alliance for Energy Productivity. https://www.airah.org.au/Content_Files/Industryresearch/05-17-A2EP_Cold_Chain_Report.pdf

[4] Dey M., Rana S.P., Dudley S., Smart Building Creation in Large Scale HVAC Environments through Automated Fault Detection and Diagnosis, 2018, London South Bank University. https://openresearch.lsbu.ac.uk/download/03e887870be82d4bfb2cf2c8000c52d83d53487527753141429c10cde69878c2/1341729/Smart%20Building%20Creation%20in%20Large%20Scale%20HVAC%20Environments%20throughAutomated%20Fault%20Detection%20and%20Diagnosis.pdf

[5] For more information on the OSI model refer to https://slideplayer.com/slide/5178864/

[6] https://developer.ibm.com/articles/iot-lp101-connectivity-network-protocols/

[7] An overview of several protocols can be found here: https://www.postscapes.com/internet-of-things-protocols/. A very detailed discussion of different protocols with respect to security can be found in Cheruvu, Sunil; Kumar, Anil; Smith, Ned; Wheeler, David M.. Demystifying Internet of Things Security,2019, Apress.

[8] Cheruvu, Sunil; Kumar, Anil; Smith, Ned; Wheeler, David M.. Demystifying Internet of Things Security,2019, Apress.

[9] https://www.youtube.com/watch?v=S9e5leRcKgg

[10] https://pdfs.semanticscholar.org/5330/68831eaa504e92b95ad2a04edb6385202525.pdf

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

[12] Ahmed, AW, Khan O.A., Ahmed M.M. and Shah M.A, A Comprehensive Analysis on the Security Threats and their Countermeasures of IoT, 2017, International Journal of Advanced Computer Science and Applications Vol 8, No 7. Available here: https://pdfs.semanticscholar.org/d2e1/4a5335e7e3bfac4d18c55d396968f1bbdd73.pdf

[13] Internet of Things (IoT) and non-IoT active device connections worldwide from 2010 to 2025. https://www.statista.com/statistics/1101442/iot-number-of-connected-devices-worldwide/

[14] Cheruvu, Sunil et al.

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

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

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

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

[19] Geers G., Cyberspace and the Changing Nature of Warfare, 2008, NATO OTAN. https://ccdcoe.org/uploads/2018/10/Geers2008_CyberspaceAndTheChangingNatureOfWarfare.pdf

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

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

[22] 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/

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

[24] Cheruvu, Sunil et al. Kindle Location 1276.

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