IN
DEGREE PROJECT ELECTRICAL ENGINEERING, FIRST CYCLE, 15 CREDITS
,
STOCKHOLM SWEDEN 2020
Evaluating the Next Generation of
Building Automation – IoT Smart
Buildings
Utvärdering av nästa generation
fastighetsautomation – IoT-smarta
fastigheter
ROBIN WINROTH
KTH ROYAL INSTITUTE OF TECHNOLOGY
Evaluating the Next Generation of
Building Automation – IoT Smart
Buildings
Utvärdering av nästa generation
fastighetsautomation – IoT-smarta
fastigheter
ROBIN WINROTH
Degree project in Electrical engineering First cycle, 15 credits
Supervisor at KTH: Lars Olov Carlheim and Gunno von Zweigbergk
Examiner: Elias Said
TRITA-CBH-GRU-2020:070 KTH
School of engineering sciences in chemistry, biotechnology and health
Abstract
Building automation systems typically use proprietary hardware and included soft-ware for their automation which can make the systems vendor-locked. Established programming standards limits the freedom of companies to improve their automa-tion systems with the growth of the IT era. The purpose of the thesis is to inves-tigate and evaluate IoT solutions and implement one of these methods as proof of concept and to elicit new aspects for analysis and discussion.
With the literature study three different methods was discovered followed by a comparative study. These methods include: Porting the existing software and moving the automation process. Replacing the hardware with smaller computers. Adding a server as translator between the building and the cloud.
The methods have different use cases with the objective of integrating a cloud service to create smarter building automation system to reduce energy consump-tion in buildings. One of the methods was proven to be most suitable for imple-mentation based on requirements set by experts in the field. The method chosen was porting a smaller portion of an existing BAS to a new programming language. The final prototype was completed with a ported program, from IEC 61131-3 standard to Java and the automation was moved from a programmable logic controller to an edge unit. The discussion focuses on different ways of optimizing the system, one of the optimization is to move the automation process to cloud computing. Energy managements are considered by collecting data and metadata in the cloud to create energy profiles for reduced energy consumption.
Sammanfattning
Fastighetsautomationsystem använder vanligtvis proprietär hårdvara och inklud-erad programvara för deras automatisering vilket kan leda till att systemen blir låsta till en leverantör. Upprättade programmeringsstandarder begränsar företa-gens frihet till att förbättra sina system under tillväxten av IT-eran. Syftet med avhandlingen är att undersöka och utvärdera IoT-lösningar och implementera en av metoderna som bevis på att lösningen är genomförbar samt att framkalla nya aspekter och data för diskussion.
Med litteraturstudien upptäcktes tre olika metoder följt av en jämförande studie. Dessa metoder inkluderar: Portering av befintlig programvara och flyttad automatiseringsprocess. Utbyte av etablerad hårdvara mot mindre enkortsdatorer. Lägga till en server som översättare mellan fastigheter och molnet.
Metoderna har olika användningsfall med slutmålet att integrera en molntjänst för att skapa ett smartare fastighetsautomationsystem för att minska energiför-brukningen i fastigheter. En av metoderna visade sig vara mest lämplig för imple-mentering baserat på olika behov ställda av experter inom fastighetsautomation. Den valda metoden består av portering av ett befintligt delsystem av fastighet-sautomationen till ett nytt programmeringsspråk.
Acknowledgements
I would like to thank Nordomatic for the support, specifically Lars Ramfelt for the opportunity to carry out this thesis and Johan Forsell for the help and support in constructing the project environment.
I would also like to thank Lars Olov Carlheim and Gunno von Zweigbergk for supervising the project and Maksims Kornevs for the advice and feedback of the thesis.
To all my fellow classmates at KTH Flemingsberg. Thank you for all the camaraderie in the class, for all the entertainment and the support and cooperation everyone shared.
Table of content
1 Introduction 1 1.1 Problem definition . . . 1 1.2 Goals . . . 1 1.3 Delimitation . . . 1 1.4 Thesis structure . . . 22 Background and Theory 3 2.1 Current systems . . . 3
2.1.1 Programming Logic Controller . . . 3
2.1.2 Input/Output modules . . . 4 2.1.3 PC-based controller . . . 4 2.1.4 Human-Machine Interface . . . 4 2.1.5 Server . . . 5 2.1.6 Communication protocols . . . 5 2.1.7 Data silos . . . 5 2.2 Industry 4.0 . . . 5 2.2.1 Internet of Things . . . 6
2.2.2 Building automation with IoT . . . 7
2.3 Related work . . . 7
2.3.1 Cloud platforms . . . 7
2.3.2 IoT BMS with cloud computing . . . 8
2.3.3 Legacy BMS with IoT . . . 8
2.3.4 Energy management . . . 8
3 Methodology 9 3.1 Literature study . . . 9
3.2 Comparative study . . . 10
3.3 Development . . . 10
3.3.1 Agile software development . . . 10
3.4 Evaluation of prototype . . . 11
4 Comparative study 12 4.1 System requirements . . . 12
4.2 Comparison criteria . . . 13
4.3 Selecting methods for evaluation . . . 14
5 Results 22
5.1 Constructing the prototype environment . . . 22
5.1.1 Heating and ventilation system . . . 23
5.1.2 End device . . . 23
5.1.3 Edge device . . . 23
5.1.4 The cloud . . . 23
5.1.5 Communication . . . 23
5.2 Software architecture design . . . 24
5.2.1 Original software architecture . . . 24
5.2.2 Current software architecture . . . 25
5.3 Final prototype . . . 26
5.3.1 Evaluating the prototype . . . 27
6 Discussion 28 6.1 Analysing results . . . 28
6.1.1 Comparison to other IoT solutions . . . 28
6.1.2 Next generation BAS . . . 29
6.2 Energy management . . . 29
6.3 Security and redundancy . . . 30
6.4 Economical aspects . . . 30
6.5 Sustainability . . . 31
7 Conclusion 32
References 33
List of Abbreviations
AI Artificial Intelligence
APIApplication Programming Interface BMSBuilding Management System BAS Building Automation System HMI Human-Machine Interface HTTPHyperText Transfer Protocol
HVAC Heating, Ventilation and Air Conditioning HV Heating and Ventilation
I/O Input, Output IP Internet Protocol
IEC International Electrotechnical Commission IoTInternet of Things
JARJava ARchive
JVM Java Virtual Machine LAN Local Area Network LED Light-Emitting Diode
MQTT Message Queuing Telemetry Transport
OPC Object Linking and Embedding for Process Control OS Operating System
PC Personal Computer
SCADA Supervisory Control And Data Acquisition SDK Software Development Kit
SSH Secure Shell
TCP Transmission Control Protocol USB Universal Serial Bus
VM Virtual Machine
1
Introduction
European Commission has estimated that buildings are responsible for around 40% of the total energy consumption and around 36% of the total CO2 emissions in the EU [1]. The European Commission has targeted energy consumption to be reduced by 20% by 2020 and 32.5% by 2030 [2].
Improving the Building automation is key for achieving the goals of the Eu-ropean Commission while retaining a comfortable environment and experience for occupants. Building automation systems controls the ventilation, heating and air conditioning such as HVAC systems as well as lighting and monitoring safety and security [3]. Building automation systems usually consists of a server, PLC units, distributed I/O and different assets such as actuators and sensors. Some of the programmable products are proprietary which means that there is a required vendor-specific software for the programming.
1.1
Problem definition
Having controllers with proprietary software has been in the industry since the beginning. This is not developer friendly and removes the modern ways of having open-source codes readily to be used across all platforms. This is a problem as the software era progresses and a problem that needs to be researched. The problem is focused on making more efficient workflows by removing proprietary software and reducing energy consumption with cloud services by using IoT solutions.
1.2
Goals
The goal is to have a proof of concept prototype of chosen IoT solution that are able to fulfill the requirements and criteria constructed by experts in the fields for evaluation. The main goal is divided into sub-goals:
1. Doing literature studies to find different IoT methods for building automa-tion.
2. Determining the best method or methods based on selected criteria.
3. Implementing the chosen method or methods as proof of concept in a case study with Nordomatic AB.
1.3
Delimitation
The thesis is conducted during a period of 10 weeks which puts the project under a time budget. This means that the prototype or proof of concept will be affected
due to it being the last phase of the thesis. The research will still be concluded with different methods.
1.4
Thesis structure
Chapter 2 involve background information, theory and related work Chapter 3 describes the methodology used for achieving the results.
Chapter 4 presents the comparative study based on selected methods and criteria. Chapter 5 displays the resulted proof of concept based on one or more methods. Chapter 6 contains the analysis and discussion of the thesis.
Chapter 7 is the conclusion of the thesis.
2
Background and Theory
This chapter provides both the background information as well as the theory be-hind earlier works and alternative methods.
2.1
Current systems
Building automation systems have different hardware components that communi-cates with each other. There are many different types of BMS but core features are shown in figure 1.
Figure 1: Building Management System
2.1.1 Programming Logic Controller
A PLC is a digital computer specially designed for rough environments to with-stand conditions such as extreme temperatures and high vibrations.
A standard PLC consists of a CPU, memory, PSU for AC to DC conversion and I/O interface. PLC can be networked together with other PLC:s and a server that
provides the information to SCADA or HMI systems [4]. They normally contain a real-time operating system within a closed system [5].
When it comes to programming, PLC follows the IEC 61131-3 standard and can be programmed with structured text, instruction list, ladder logic, function block diagram or sequential function chart. Most PLC in building automation is programmed using ladder logic [4]. The programs are first written on a PC then downloaded into the PLC via direct connection or over a network. The program is stored in flash or RAM with backup battery connected [6].
PLC uses USB, Ethernet, RS-232 and more to communicate with external devices, other PLC units and servers or SCADA/HMI systems. The communica-tion uses protocols such as Modbus, TCP/IP, Ethernet/IP and more. Companies with production of controllers and systems may use a specific type of protocol for communication between their units [7].
2.1.2 Input/Output modules
I/O modules consists of input or output terminals that can be either analogue or digital for different types of actuators [4]. They can either be mounted directly to a controller or distributed over distance. Distributed modules are normally connected over a communication cable and communicates using protocols such as modbus, TCP/IP or similar communications protocols.
Distributed I/O modules are often used because the PLC and clusters of actu-ators and sensors are spread between a large distance. The use of distributed I/O makes the wiring less problematic to configure, troubleshoot or replace, which can make it more cost effective than single wiring.
2.1.3 PC-based controller
A PC-based controller usually consists of windows operating system with propri-etary software used to program in any of the common C languages. Beckhoff has a PC-based controller that uses TwinCAT automation software and can create sim-ilar functionalities as a PLC but with an open architecture rather than a closed one that PLC has [8].
2.1.4 Human-Machine Interface
Human machine interface is a monitor on the site of the building automation sys-tem or a computer application that acquires real-time data from remote sites also known as SCADA. The SCADA system can be based inside a controller room or cloud-based. Technicians use these systems to monitor or control on-site equip-ment and processes.
2.1.5 Server
A server is used for communication between HMI systems. The communication standard between server and client was earlier called the OPC (Object Linking and Embedding for process control) but later renamed to Open Platform Commu-nication. The OPC client is the HMI monitor or the SCADA system and the OPC server is the computer that collects and gathers all the data from PLC or DCS [9]. 2.1.6 Communication protocols
There are several communication protocols in building automation industry, some are proprietary and some are open standards. Some wired open communication protocols include: BACnet, LonWorks, Modbus and DALI. Wireless open commu-nication protocols include: EnOcean, Wireless M-bus and 802.15.4 protocol. The protocols have their respective areas where they are more advantageous than other protocols.
BACnet and LonWorks are similar communication protocols, BACnet is more applicable over different areas, more scalable and works best with management systems. DALI works best for lighting controls and Zigbee is the more reliable and secure protocol between the two wireless protocols mentioned [10].
Modbus is a protocol that works with easy tasks such as enabling alarms, reading sensor data and enabling actuators. Modbus does not have any security measurements installed.
2.1.7 Data silos
In building automation data silos refers to data in a building. The data inside the building is locked within its system and not shared between other buildings. By locking the data within the building others cannot use the information to create analysis, prediction or profiles based on patterns. Patterns that may be used in building automation to save energy or create more comfortable environment for oc-cupants. "In short, data silos cause wasted resources and inhibited productivity." [11].
2.2
Industry 4.0
Industry 4.0 does not only cover the classic industries but rather anything that could be considered "smart" such as "smart cities" or "smart buildings". The industry 4.0 is an advancement in technology that could improve the industry in ways not yet mainstreamed such as IoT, cloud computing, AI, augmented reality or wireless communications. These technologies will be used to upgrade the industry 3.0 of computerized and automated industries to the next generation.
To a unified network for information sharing and data exchange for making decisions [12].
By connecting all of the different machines and devices in an industry they can communicate with each other and share information between them and thus collectively use their shared information and make decisions based on this information.
2.2.1 Internet of Things
Internet of Things or IoT is a technology that is used to connect devices in a network that can exchange data between the internet through a gateway. IoT is often used when talking about "smart systems". Big chunks of data can be collected through many different devices and then be analysed to be used in a "smart system" to automate actuators. The IoT architecture consists of a device (sensor of sorts), an edge gateway and the cloud [13].
Figure 2: IoT architecture
2.2.2 Building automation with IoT
The IoT architecture can be compared to the current building automation archi-tecture:
• The cloud would represent the HMI or SCADA system.
• The edge gateway would represent the server and PLC units. This would also include an on-site HMI to handle loss of cloud connectivity in emergencies. • The device would represent the actuators and sensors.
IoT integration in building automation can provide the following:
• It will provide an automation system similar to that of the normally installed building automation systems.
• The ability to compare and combine data from multiple buildings to optimize their performances.
• The potential of integrating new smart devices into different areas of the building for future applications.
With the development of industry 4.0 newer PC-based controllers have been introduced such as ctrlX from Bosch Rexroth [14] and Revolution Pi from Kunbus [15]. They provide similar functionalities as a regular PLC but on a linux based operating system that can be programmed with any programming language.
2.3
Related work
This section goes over related work. This thesis focuses on IoT solutions for building automation and will therefor be looking at everything related to IoT such as: Cloud platforms, different software solutions and energy management.
2.3.1 Cloud platforms
This thesis [16] compares different cloud service providers for IoT in HVAC systems. They compared providers such as Amazon AWS IoT, Google Cloud IoT, Microsoft Azure IoT and more. The research was later narrowed down to Amazon AWS and Microsoft Azure due to restrictions and those being the leading cloud providers. The comparison is based on criteria that was chosen from literature studies.
The conclusion in the thesis shows that both of these cloud service providers are suitable for cloud integration in IoT building automation. IoT BMS that needs more cloud service provider functionalities such as storage or data processing would benefit more from Amazon AWS. IoT BMS that will be using integration with external applications such as web pages would benefit more from using Microsoft Azure.
2.3.2 IoT BMS with cloud computing
Implementation of IoT to smart building using cloud computing is shown in paper [17]. The setup consists of a raspberry pi, arduino and sensors. The arduino and sensors acts as the distributed I/O and the raspberry pi acts as the gateway between the I/O and the cloud. It also acts as the automation logic for the actuators. Microsoft Azure is used as the cloud service where users and admins can read the collected data.
2.3.3 Legacy BMS with IoT
This paper [18] shows integrating IoT with currently installed BMS where the IoT is the communicate between the different proprietary hardware and software to exchange data with the cloud. With the cloud they are able to use different services and monitoring systems. This method was done because they wanted to open up the data silos that different buildings with legacy systems have and combine them into prediction models.
2.3.4 Energy management
A research into energy usage and potential energy management in buildings is shown in paper [19]. By collecting data into models they were able to create profiles used for managing energy usage of appliances or devices. The experiment was conducted over three buildings and by creating profiles from two of the buildings the third building could use the profiles for energy savings of between 14% and 30%.
3
Methodology
This chapter describes the methods used to reach the defined goals. Information from the literature study is used for defining the architecture of different methods. A comparative study is then used to create criteria for the methods to differentiate them. The development is the implementation of method as proof of concept where the criteria sets the precedence of which methods to be implemented.
Figure 3: Methodology
3.1
Literature study
The purpose of the literature study is to find relevant information about build-ing automation systems and IoT from different theses, papers and articles. The building automation systems and IoT information would provide useful in under-stand their different architecture and entirety. While the researched work will be useful in understanding what already exists, what their conclusions are and future recommendations.
The key points of the literature study:
• The architecture of building automation systems. • The architecture of Internet of Things.
• IoT integration with building automation systems.
• Reduced energy consumption with IoT in building automation systems. • Cloud platforms in regards to IoT in building automation systems.
3.2
Comparative study
Multiple methods are selected from the literature study and evaluated based on criteria set by the standards of a functional system and requirements set by the company. The methods are based of the IoT architecture and used in the building automation systems to compare different tiers in the architecture to decide which components would be able to be replaced or upgraded.
The methods should consists of both hardware, software and the protocols that is used between the different devices. The methods are evaluated based on criteria in order to determine which methods would be most appropriate in current building automation systems.
To determine if the most appropriate method is able to be integrated into a building as a functional automation system it is required to develop it as proof of concept.
3.3
Development
The development phase is the implementation of the IoT solution which will be using different strategies and methods in order to create an effective work environ-ment.
3.3.1 Agile software development
The agile development is constructed by using different methods and tools. All of the software will be saved in version using a version control system. This will save different stages of the development as well as the option to share the development with others.
A documentation of the software will be documented so that future development of other parties may continue with ease. As per agile workflow the
documentation will be concise and not documented in such details that it will become a time cost.
The workflow is divided into different assignments such as: What needs to be done. What is already done. What needs to be fixed.
3.4
Evaluation of prototype
The final prototype will be evaluated by the requirements and criteria used in the comparative study. It will also be analysed against other methods and how it performs as a BMS in regards to different aspects. Such aspects include economical, energy management, security and redundancy.
4
Comparative study
This chapter describes the methods that is chosen to be evaluated and which requirements and criteria they will be evaluated to.
4.1
System requirements
The requirements put on the implementation of the IoT method is defined by Nordomatic which consists of a partial HVAC system and software development preferences. Nordomatic was selected because of their experience and expertise within the field of BAS while also extensive networks and relationships. The requirements will be used as part of the criteria when evaluating the methods. The implementation of the method will be based on a real version of a heating and ventilation system from a building.
Requirement 1 The programming language of the system should consists of a high-level language that is not of the IEC 61131-3 standard.
Requirement 2 Preferably; The developed software along with necessary libraries and configuration files should be packaged in a singular container as such it can be deployed across multiple different platforms.
Requirement 3 The automation system has to be able to be installed with a legacy or a new building automation system.
Requirement 4 The automation system needs to be able to function in a simulated ventilation and heating system.
4.2
Comparison criteria
The article "How to Evaluate Building Automation Systems" [20] was used for the criteria in order to base the methods to relevant key points in regards to BMS. The criteria are based on the requirements set by Nordomatic AB and relevant criteria selected from the article.
Criteria 1 Openness
Criteria 1.1Open protocols
The criteria refers to if the protocols being used is open and not vendor-locked. Which means can anyone use the protocols? Criteria 1.2Open software
This criteria is about if software used in the method such as libraries, API and SDK is open to use for anyone.
Criteria 2 System support Criteria 2.1Legacy support
This criteria is in regards to legacy systems. Is the method able to integrate with legacy systems?
Criteria 2.2Supported protocols
The criteria is based on how well the protocols used in the method is supported across multiple vendors and platforms.
Criteria 3 Control architecture Criteria 3.1Redundancy
This criteria refers to if methods are able to run successfully if a link in the system fails. Redundancy is meant to have an extra link ready to run to make the system more stable.
Criteria 3.2Design standards
This criteria considers whether the architecture is staying with the standards in the industry such as naming conventions, tools and
documentation; used mainly for maintenance, upgrades or replacements.
4.3
Selecting methods for evaluation
While there are many different methods for IoT with BMS, three methods was chosen to be evaluated. There are two methods chosen from literature study and one method that was introduced by experts at Nordomatic. The methods consists of different implementation and functionalities but at its core they are all IoT. IoT BMS cloud computing
The first method that is to be evaluated is from "IoT framework for smart buildings with cloud computing" [17] described in related work. It is an IoT framework for smart buildings with completely new hardware and software for the automation and control. Computing from the cloud is used for controlling the logic of the automation process over the internet.
IoT integration with legacy BMS
The second method that is to be evaluated which is from "Open BMS – IoT driven Architecture for the Internet of Buildings" [18] described in related work. Their approach of implementing IoT in building automation was to use an already existing BMS and build IoT ontop of it by using a gateway for language translation between the system and the cloud.
Porting BMS to IoT
The third method consists of a combination of both IoT BMS cloud computing and IoT integration with legacy BMS. It follows both the typical IoT
architecture while still having legacy support. By moving the automation logic to the server, the need for PLC will be obsolete which will make the BMS into a centralized automated system. The I/O units will remain as they still provide their functionality to the system.
4.4
Evaluating methods
The methods are evaluated based on the comparison criteria. This will determine which methods are stronger in different areas of the BMS and also be the basis for which method will be implemented. Each criteria will be evaluated against each method.
All methods have their strengths and weaknesses which are not evaluated with the criteria. Based on the criteria the following order with methods are
concluded as the most suited for IoT BMS: 1. IoT BMS cloud computing
2. Porting BMS to IoT
3. IoT integration with legacy BMS
Since IoT BMS cloud computing is not legacy compliant as per the requirements set by Nordomatic, the most suited IoT BMS falls on porting BMS to IoT which are compliant with all requirements. This means that porting BMS to IoT will be implemented.
Criteria 1.1 Open protocols
IoT BMS cloud computing
The protocols used in IoT BMS cloud computing are either open-source or open standards. This means that this method are open protocol compliant and not locked into any vendor specific protocols. The communication can be used over Bluetooth, serial or USB connection which are using open communication
standards. The communication between the gateway and the cloud is done using secure internet protocol.
IoT integration with legacy BMS
The protocols used in this method consists of IoT compliant protocols such as MQTT and REST. As for the communication between the gateway and the BMS it is using LINC middleware to act as the translator between different protocols such as BACnet, Modbus and more. See criteria 1.2 about LINC middleware as an open software. As far as open protocols, this method passes the criteria. Porting BMS to IoT
The protocols used in this method are any of the communications protocol standards such as BACnet, Modbus and LonWorks which are used between the gateway and a remote I/O. The connection to the cloud is done using MQTT and HTTPS protocols. These protocols are all open standards.
Comment
All the methods support open standard protocols for communication.
Criteria 1.2 Open software
IoT BMS cloud computing
The software or programming language being used are Arch Linux for the OS in the gateway and node.js service for managing each I/O unit. The control logic is programmed using JavaScript for sensor reading or actuators control. The
software are all open-source or free programming languages. IoT integration with legacy BMS
The software being used in this method are mainly the LINC middleware. LINC is neither open standard or open-source. The software is closed behind the company that developed it. Motorola Remote Terminal Unit is used as the gateway which is a linux based system. This unit is vendor specific as well as the system not being open-source.
Porting BMS to IoT
The software is created using a high-level programming language. The gateway consists of a Linux based OS and is proprietary, however the software is able to be moved and used in a open-source Linux system.
Comment
IoT integration with legacy BMS have multiple software being vendor-locked. Porting BMS to IoT contains some proprietary software which can be replaced by open-source. IoT BMS cloud computing are using open software.
Criteria 2.1 Legacy support
IoT BMS cloud computing
This method has a new BMS architecture which would require installed BMS to be reinstalled with the IoT hardware. This method does not have legacy support. IoT integration with legacy BMS
This method has support for both legacy and non-legacy BMS. The method can only be used in buildings where a BMS has already been installed which means no new installations is required.
Porting BMS to IoT
Porting BMS to IoT can be used in both legacy or non-legacy BMS as well as new installations of BMS. However a porting of the logic is needed in order to remain the legacy system into a new IoT compatible architecture.
Comment
IoT BMS cloud computing lacks legacy support and porting BMS to IoT has partial legacy support depending on the installed BMS. IoT integration with legacy BMS has legacy support.
Criteria 2.2 Supported protocols
IoT BMS cloud computing
This method is using raspberry pi and arduino which means extensions boards can easily be mounted and therefor are able to support all the common BMS protocols used in communication.
IoT integration with legacy BMS
This method is used on an existing Motorola Remote Terminal Unit which can support most common BMS protocols.
Porting BMS to IoT
This method has the possibility to support all of the common BMS protocols by using a Linux based gateway and replaceable I/O modules.
Comment
All of the methods have support for the open protocols used in BMS.
Criteria 3.1 Redundancy
IoT BMS cloud computing
This method can use different communication protocols to ensure redundancy link between the arduino and gateway in case one of the links fails the other can be used. It is also using decentralized control logic for fail-safe in case the
connection to the cloud is lost. No power redundancies was introduced in the method.
IoT integration with legacy BMS
This method does not have any redundancy links, backup coding schemes or redundancy power in case of failures expressed in the paper.
Porting BMS to IoT
This method does not have redundancy links to the I/O units. Depending on what I/O unit is being used it may have backup coding schemes. No power redundancies is being used in this method.
Comment
IoT BMS cloud computing has the most redundancies in place in case of failures. Porting BMS to IoT may have backup coding schemes depending on installed I/O and redundancy links to the gateway unit. IoT integration with legacy BMS has no redundancies in place.
Criteria 3.2 Design standards
IoT BMS cloud computing
The design standards used in this method are the protocols and architecture. The protocols used are common BMS protocols. The architecture consists of standard BMS such as gateway, controllers and sensors. The tools used for implementation are documented, however no public documentation was used for the software. IoT integration with legacy BMS
The method is implemented on an existing installed BMS which should be using all the design standards. The method does not contribute to any of the design standards.
Porting BMS to IoT
The design standards used in this method are the protocols. The protocols used are common BMS protocols. The architecture consists of a gateway, distributed I/O and sensors which is not of a standard BMS. The implementation is
documented, however not open-source or for the public. Comment
The criteria is hard to evaluate based on a paper with no detailed
documentation. All methods are following protocol standards and IoT BMS cloud computing and IoT integration with legacy BMS are following architecture standards. The tools used for implementation are documented but missing detailed public document for implementation for all methods.
5
Results
This chapter describes the development for which the results was achieved. Con-structing the prototype environment and creating the software architecture leading to the final prototype.
5.1
Constructing the prototype environment
The porting of an existing HV system is done in a simulated environment which provides information of different states of the I/O ports through a web interface. The environment consists of an end device, edge device and a HMI.
Figure 4: Prototype environment
5.1.1 Heating and ventilation system
The development is created on an existing HV system that is scaled down to a smaller system. A real HV system would be using temperature sensors, air pressure sensors and smoke detectors to control fans, heat exchanger, pumps and dampers. Due to constraints these sensors and actuators are not used in the simulated environment.
5.1.2 End device
The end devices are restricted to only two I/O units. The distributed I/O consists of two Regin expansion units with 28 I/O ports each. The expansion boards have the option to change their IP address and different communication options with a supplementary controller. The components that are connected to the expansion boards are a temperature sensor, a switch and a few LED’s for verification of tests.
5.1.3 Edge device
The edge device consists of a virtual machine that is run on a PC. The virtual machine contains proprietary software that provides a web interface that is able to display and control the sensors and actuators that is connected to the different I/O units.
5.1.4 The cloud
The solutions provided by cloud services such as Azure Cloud or Amazon AWS would not provide any benefits to such a small scale system therefor the
integration was not implemented on the system.
Instead the cloud is replaced by the web interface which is used as the controlling and monitoring of the system, the HMI. See Appendix A for a visualization of the web interface.
5.1.5 Communication
The connection between edge device and end devices is established with Ethernet cables over LAN. The communication is done using Modbus TCP. The
communication is normally accomplished by reading the expansion unit manuals and acquired knowledge of the Modbus TCP protocol. However, this was already abstracted within the web interface and minimal work was required to set up the communication.
5.2
Software architecture design
5.2.1 Original software architecture
The program maps the I/O addresses to a variable with appropriate datatype. The program is divided into smaller subprograms that runs over a specified cyclic time. The PLC is using scan cycles for the controlling process.
The scan cycles consists of 3 stages:
1. Reads the input values from the I/O modules. 2. Performs the logic.
3. Outputs the new values.
Figure 5: Scan cycle
The current program for the HV system are written in structured text and functional block diagrams. The code consists of primitive data types, user defined data types and functions. The information provided by the sensors are stored in primitive data types while processed data can be stored in user defined data types. The function blocks performs the logic for controlling the different processes.
Figure 6: PLC to I/O communication
5.2.2 Current software architecture
The original software architecture is not lacking in design. The process needs to be moved to another device other than the PLC as well as using a high-level programming language that is not bound to any proprietary software.
The control logic that normally runs in the PLC was moved to the virtual machine and is programmed in Java. A JAR file is created to archive the application for easier deployment to the virtual machine.
The virtual machine consists of the web interface which holds the mapping for the I/O addresses to a corresponding key value. A database is used to store the values from the I/O mapped with its key. Once a key value has changed the I/O is updated with its new value.
Figure 7: Edge to I/O communication
Database classes are developed in Java in order to obtain or update information from the database. A model is created to represent database key values with unique names and tags. Defined data types and functions from the original software is ported to Java and modified to fit the object-oriented design.
In order to verify that the objects used in the program are working as intended unit tests are deployed. By creating unit tests the steps required to debug are reduced in case the main code is not working as intended.
Figure 8: Performed unit tests
5.3
Final prototype
The final prototype is able to perform automated controls of the connected I/O. It is able to create a cloud connection, however it would not provide any benefits to this prototype and therefor the HMI was enough for monitoring and
controlling the system on site.
Figure 9: Testbed with LED and two Regin I/O modules
5.3.1 Evaluating the prototype
Evaluating the final prototype to the requirements set in chapter 5: Requirement 1. The system is programmed with Java.
Requirement 2. A produced executable JAR file is able to be deployed across multiple different platforms for which a JVM exists.
Requirement 3. Because the HV system has been ported it works with both legacy systems and is able to be installed in newer systems.
Requirement 4. The prototype contains a fully ported HV system. Although only one subsystem is fully tested and theoretically operational.
Criteria. All of the criteria are met except for Criteria 1.2.
6
Discussion
This chapter discusses and analyses the results as well as analysing how the IoT so-lution could affect environmental, security and economical aspects if implemented at an enterprise level.
6.1
Analysing results
The results of the implementation shows that porting installed BMS is achievable in removing the proprietary software obstacles used with different PLC suppliers. This opens up new opportunities such as connecting every end device to the cloud for data exchanges.
The final prototype was using a centralized controller to control the automation process from a single point. This design opens up for risks if the controller was to malfunction or the communication connection was to break.
6.1.1 Comparison to other IoT solutions
If porting is done for the first time, it would be very time-consuming task for programmers to recreate all of the code used, test it and make sure it is safe for re-deploy. The more buildings that are ported with this method the less work will be required for next porting, however, there will always be an initial time cost. Porting of a system will open up for new technological advancements. The method IoT integration with legacy BMS would be the easiest to install, although this method would limit improvements to the actual automation process.
The method that is using cloud computing for the BMS with IoT connected hardware is a very strong solution for creating smart buildings. It requires same time to create the software for the controller as the implemented method. It has the same openness and uses similar non-proprietary hardware.
If the aim is to open up data silos in buildings then method with translator is sufficient. If the aim is to create smarter controlled buildings then either porting if implemented on an existing system or cloud computing for newer installations.
6.1.2 Next generation BAS
The final prototype was able to monitor and affect the automation process through a web interface, although an actual cloud service was never used. "Evaluating IoT cloud platforms in the context of smart buildings" [16] shows that Azure and AWS are two cloud services that are recommended for BMS. To further develop the prototype Azure offers services to advance the automation to the next generation.
Kubernetes can be used to deploy containerized application such as the controller logic used in automation systems. By using a database the deployed application can read and write to it based on the computed logic. The centralized controller inside the buildings can then be used as to only read and write to the database and not to perform any logic, because that now resides inside the Kubernetes. The database can then be used to create a web application used for monitor and control of the system.
6.2
Energy management
The developed prototype does not provide any direct energy efficiencies. The developed program can however be packaged and used in cloud computing or make use of databases to store different types of data used for prediction algorithm.
In order to reduce energy consumption the computations could be moved to another company such as cloud service providers. Eliminating unnecessary usage of sensors, lights or actuators will also save energy consumption.
The biggest focus in reducing energy consumption should be on the heaters, coolers and ventilation as they demand the most energy, moving the
computations to the cloud will not solve this. One way to reduce it is by using collected data and metadata for prediction algorithms.
The paper "How can We Tackle Energy Efficiency in IoT Based Smart Buildings?" [19] shows an energy saving of about 23%. By collecting data of energy usage and designing energy profiles to reduce energy consumption without the loss of comfort for occupants.
6.3
Security and redundancy
The computer that is hosting the web interface as well as controlling the automa-tion process needs to have security measurements to prevent malicious intenautoma-tions to the system. These measurements include:
• Workstations used for monitoring needs to use login information to access the web interface.
• Remote connections made to the workstations needs to use secure connec-tions such as SSH or VPN.
• Only allow workstation IP address to connect to the web interface with a potential backup.
The idea of having backups installed to prevent fatal outcomes in case of
controller- or link failures was presented in the paper "IoT framework for Smart Buildings with Cloud Computing" [17]. To assure that essential sensors and actuators are running each I/O unit needs to be programmable with a fallback program that will run if link failure occurs. This is to prevent damage to property, occupants or personnel.
It is important to be able to control or monitor the system remotely. This means that an internet connection is essential for connecting to the system. By using multiple internet service providers for connection it reduces the risk for failures to access the system remotely.
6.4
Economical aspects
By removing the PLC units it also eliminates the need for IEC 61131-3
standards. This removes for the cost of the PLC units and opens up for unified programming languages that are able to communicate with different APIs.
The biggest economical gain is from reducing HVAC energy consumption as they consume the most energy [19]. Porting away from IEC 61131-3 standards makes it easier to use cloud services. It is still possible to use the services with IEC 61131-3, although a translator is needed. Cloud services can then be used in reducing energy consumption as mentioned in 7.2.
6.5
Sustainability
The goals set by the European Commission to reduce energy consumption by 20% by 2020 and 32.5% by 2030 is not impossible to achieve. The paper "How can We Tackle Energy Efficiency in IoT Based Smart Buildings?" [19] is already showing energy savings of about 23%. This means that the goals for 2020 is already possible.
Implementing this method in a few buildings would only affect a small portion of the total energy consumption. This means that most existing buildings,
especially with older systems would have to implement an IoT BMS solution to easier support energy profiles while also creating a more effective system. In order to achieve the goals of the European Commission the property owners that are using legacy BMS needs to upgrade and maintain their systems. The cheapest solution might work short-term, however, it is recommended to choose a method that would have a higher potential of energy savings for the long-term future. That is, a method that would offer most freedom to the automation while also being easily upgradeable and replaceable.
7
Conclusion
The aim of this thesis is to evaluate different IoT solutions for building
automation systems and to implement one or more of these solutions on a small scale. Literature studies and research helped to find different IoT methods for building automation. Researched papers written about IoT BMS solutions illustrates ways of implementing IoT BMS which are evaluated and compared against selected requirements and criteria. The chosen method were implemented in a case study with Nordomatic AB.
Cloud services was never implemented in the prototype because they would not provide any benefits to such a small scale project. There was insufficient data to create any energy efficient profiles. By replacing controllers such as the classic PLC units and the IEC 61131-3 standard it removes halts in the progression for the industry. PLCs are perfected to do one job very well but they are very restricted, replacing these could open up for consequences which requires redundancy to be installed.
This thesis and the proof of concept system can be used by Nordomatic to evaluate or further develop smarter systems for energy efficient solutions. It may also help other building automation companies in choosing an appropriate solution based on their needs.
The selected IoT method was constructed successfully with a prototype as proof of concept, by porting the legacy program to a new programming language and moving the automation to an edge device. It was able to fulfill the requirements and most of the criteria. This makes this method a potential candidate when chosing between different IoT BMS solutions.
For future work, different wireless technologies could be researched as to create a more IoT specific solution by "connecting every single device and node" instead of having clusters of sensors or actuators on a single I/O unit.
References
[1] European Commission. New rules for greener and smarter buildings will in-crease quality of life for all Europeans. url: https://ec.europa.eu/info/ news / new rules greener and smarter buildings will increase -quality-life-all-europeans-2019-apr-15_en(visited on 03/30/2020). [2] European Commission. Climate strategies & targets. url: https : / / ec .
europa.eu/clima/policies/strategies_en(visited on 03/30/2020). [3] Elena. What Is A Building Automation System (BAS)? (Functions And
Ben-efits). url: https://www.opensourcedworkplace.com/news/what-is-a-building-automation-system-bas-functions-and-benefits (visited on 04/04/2020).
[4] Industrial Automation Asia. Industrial Applications of Programmable Logic Controller. url: https://www.iaasiaonline.com/industrial-applications-of-programmable-logic-controller-2/ (visited on 03/30/2020).
[5] Eric Byres. PLC Security Risk: Controller Operating Systems. url: https: / / www . tofinosecurity . com / blog / plc security risk controller -operating-systems(visited on 03/30/2020).
[6] Frank Lamb. PLC Memory. url: https://automationprimer.com/2016/ 08/28/plc-memory/(visited on 03/30/2020).
[7] Dipali Chaudhari. 10 Most Used PLC Communication Protocols in Industry. url: https : / / dipslab . com / plc communication protocols used -industry(visited on 03/30/2020).
[8] Beckhoff.com. Open, PC based control technology. url: https : / / www . beckhoff.com/Automation/ (visited on 03/30/2020).
[9] opcfoundation.org. What is OPC? url: https : / / opcfoundation . org / about/what-is-opc/(visited on 03/30/2020).
[10] Karan Lohia et al. Open Communication Protocols for Building Automation Systems. url: https://www.sciencedirect.com/science/article/pii/ S187705091931720X/ (visited on 05/18/2020).
[11] Alienor. What is a Data Silo and Why is It Bad for Your Organization? url: https://www.plixer.com/blog/data-silo-what-is-it-why-is-it-bad/ (visited on 04/04/2020).
[12] Bernard Marr. What is Industry 4.0? Here’s A Super Easy Explanation For Anyone. url: https://www.forbes.com/sites/bernardmarr/2018/09/ 02/what- is- industry- 4- 0- heres- a- super- easy- explanation- for-anyone/#3cfb71b29788(visited on 03/31/2020).
[13] Steve Ranger. What is the IoT? Everything you need to know about the Internet of Things right now. url: https://www.zdnet.com/article/ what- is- the- internet- of- things- everything- you- need- to- know-about-the-iot-right-now/ (visited on 03/31/2020).
[14] Boschrexroth. INDUSTRY 4.0 NEEDS A COMPLETE AUTOMATION SO-LUTION. url: https://apps.boschrexroth.com/microsites/ctrlx-automation/en (visited on 03/31/2020).
[15] Kunbus. Open Source IPC based on Raspberry Pi. url: https://revolution. kunbus.com/ (visited on 03/30/2020).
[16] Gustaf Bohlin and Anton Hellbe. Evaluating IoT cloud platforms in the context of smart buildings. url: https : / / muep . mau . se / bitstream / handle / 2043 / 28214 / Thesis _ paper _ final _ Anton _ Gustaf . pdf (visited on 04/04/2020).
[17] Enrique Carrillo et al. IoT framework for Smart Buildings with Cloud Com-puting. url: https://www.researchgate.net/publication/308602593_ IoT_framework_for_smart_buildings_with_cloud_computing (visited on 04/04/2020).
[18] Alan McGibney et al. Open BMS – IoT driven Architecture for the Internet of Buildings. url: https://www.topas- eeb.eu/images/2016_IECON_ Open_BMS.pdf(visited on 04/06/2020).
[19] M. Victoria Moreno et al. How can We Tackle Energy Efficiency in IoT Based Smart Buildings? url: https : / / www . ncbi . nlm . nih . gov / pmc / articles/PMC4118407/(visited on 04/06/2020).
[20] Phil Zito. How to Evaluate Building Automation Systems. url: https:// buildingautomationmonthly.com/evaluatebas/ (visited on 04/06/2020).
Appendices
Appendix A
Image 1: Reproduction of the web interface
TRITA CBH-GRU-2020:070
