Building Management System Extension

Building Management System Extension

Student Name: Divay PrakashRoll Number: 2014039

BTP report submitted in partial fulfillment of the requirementsfor the Degree of B.Tech. in Computer Science and Engineering

on April 18, 2017

BTP Track: Engineering

BTP AdvisorProf. Hemant Kumar

Indraprastha Institute of Information TechnologyNew Delhi

Student’s Declaration

I hereby declare that the work presented in the report entitled Building Management Sys-tem : Scheduler and a web service to log data and control devices submitted byme for the partial fulfillment of the requirements for the degree of Bachelor of Technology inComputer Science & Engineering at Indraprastha Institute of Information Technology, Delhi, isan authentic record of my work carried out under guidance of Prof. Hemant Kumar. Dueacknowledgements have been given in the report to all material used. This work has not beensubmitted anywhere else for the reward of any other degree.

.............................. Place & Date: .............................Divay Prakash

Certificate

This is to certify that the above statement made by the candidate is correct to the best of myknowledge.

.............................. Place & Date: .............................Prof. Hemant Kumar

2

Abstract

The building management HVAC(heating, ventilation and air conditioning) system for PhaseII of IIIT-Delhi campus is designed to take care (and advantage) of diversity of use. Insteadof using large AHUs(Air Handling Units), we will have individual units in faculty rooms, labs,and other spaces. This would allow us to condition air of the spaces that are occupied and thesystem would be able to maintain desired temperature more closely. The disadvantage of thisapproach is higher capital cost and a larger I/O points for BMS but the running cost will besaved. In this project we are developing a scheduler hosted on a web server to control the ACsvalves connected through Raspberry Pi and Arduino.

Keywords: building management system, scheduler, web server

Acknowledgments

I take this opportunity to express my deepest gratitude and appreciation to all those who havehelped me directly or indirectly towards the successful completion of this project.

I would like to express my sincere gratitude to my advisor Prof. Hemant Kumar for providinghis invaluable guidance, comments and suggestions throughout the course of the project.

i

Contents

List of Figures iii

List of Abbreviations iv

1 Introduction 1

1.1 BMS for phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 BMS for phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Problem Statement 3

3 Previous Work 4

4 Architecture 5

5 Design 6

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.2 Central server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.2.1 Design specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.2.2 Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.3 Sub-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.1 Design specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3.2 Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6 Implementation 9

6.1 Central server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.1.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.2 Sub-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.2.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

7 Working Prototype 12

ii

List of Figures

3.1 HTML templates for the central server frontend . . . . . . . . . . . . . . . . . . . 4

4.1 Block diagram of the building management system project . . . . . . . . . . . . . 5

5.1 Higher level control modules of the building management system . . . . . . . . . 6

6.1 Flowchart of data logging functionality provided by Raspberry Pi sub-server tomicrocontroller devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

iii

List of Abbreviations

AHU Air Handling Unit

API Application Program Interface

BMS Building Management System

CSS Cascading Style Sheets

CSU Ceiling Suspended Unit

DBMS Database Management System

FCU Fan Coil Unit

GUI Graphical User Interface

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HVAC Heating Ventilation and Air Conditioning

I/O Input/Output

JSON JavaScript Object Notation

LAN Local Area Network

MAC Media Access Control

OS Operating System

REST Representational State Transfer

SoC System on Chip

SSH Secure Shell

VFD Variable Frequency Drive

WiFi Wireless Fidelity

iv

Chapter 1

Introduction

1.1 BMS for phase I

HVAC for the Phase I buildings (Academic, lecture halls and library building) of IIIT-Delhi

campus used large floor mounted AHU’s to condition large spaces except lecture halls which

were served by CSU’s (ceiling suspended units). Library building has one AHU per floor feeding

all the labs and rooms. The academic building has 6 AHUs (three serving A wing and the other

three wing B). Hostels have one FCU per room. The large AHUs of the academic block control

volume of cold air by reducing the fan speed using VFD drives. As the area per AHU is large and

the need very diverse (labs with varying number of occupants and equipment vs faculty rooms),

the HVAC system is not very energy efficient and uniform temperature can’t be maintained.

The HVAC system has a very basic centralized control that can set temperature to be achieved

in each one of the AHUs or CSUs. It also allows switching on/off, monitoring parameters etc

centrally. Other than AHUs/CSUs it can display status and parameters of chillers, cooling

towers and hot water generator.

In BMS/ HVAC terminology each point that is controlled or read is an I/O point and an I/O

summary is prepared for any BMS installation to estimate the cost. The I/O points are of 4

types - digital input, digital output, analog input and analog output. In phase I, we had chosen

to only include I/O that either needed to be controlled or the I/O that were to be sensed and

used for controlling to contain cost. The system was provided by Trane.

Later a parallel system for monitoring and data collection was implemented by a research group

led by Dr Amarjeet Singh. This group installed wireless temperature sensors (13) and Ethernet

based power meters (500) all over the campus to optimize HVAC and energy use based on data

collected.

1

1.2 BMS for phase II

The HVAC for Phase II of IIIT-Delhi campus is designed to take care (and advantage) of diversity

of use. So instead of large AHUs, we will have individual units in faculty rooms, labs, and other

spaces. This would allow us to condition air of the spaces that are occupied and the system

would be able to maintain desired temperature more closely. The disadvantage of this approach

is higher capital cost and a larger I/O points for BMS but the running cost will be saved.

However, a significant cost saving would also be introduced by this approch due the use of ESP

WiFi modules and leveraging the existing wireless network infrastructure of IIIT Delhi. The

use of these modules for the network connection needs of the microcontroller devices provides us

with a cost saving as there is no need for Ethernet cable runs to each of these numerous devices

and the ESP modules provide a direct WiFi connection to the existing wireless routers. Also, it

allows us greater flexibility of location for the microcontroller devices.

2

Chapter 2

Problem Statement

Given the large number of units to monitor and control, the cost of BMS was estimated to be

very high. In addition, for phase II, the traditional system would be close-ended and proprietary.

Most of the cost (about 60%) would have been in the wiring the large number of units to

controllers. This cost can be saved if individual WiFi-based controllers (500-600) were to be

deployed. These wireless devices can use the existing institute LAN infrastructure to further

save costs. In addition, groups of these devices would be controlled by Raspberry Pi devices

running a custom Django server which would further be controlled by a central Django server.

This central server would provide a GUI for administrators to monitor and control the entire

BMS system.

3

Chapter 3

Previous Work

This project is a continuation from the previous semester. A summary of the work done previ-

ously is as follows -

• Designed and implemented the frontend for the central server

• Documented Python code written for the Raspberry Pi sub-server

• Documented Arduino code written for the microcontroller

• Ported sub-server from BaseHTTPServer to Django server

Figure 3.1: HTML templates for the central server frontend

4

Chapter 4

Architecture

Central server

Sub-server

ESP WiFi moduleMicrocontroller

AHU

Wired Ethernet

WiFi

Figure 4.1: Block diagram of the building management system project

The BMS/ HVAC system, is structured in the manner described by figure 4.1. At the lowest

level is the AHU, which performs the actual cooling/heating functionality of the system. It is

controlled by the microcontroller. The microcontroller monitors various system parameters and

accordingly runs the AHU. The microcontroller runs in a master-slave configuration wherein the

master is an ESP wireless module which is responsible for communication with further control

levels. This system is in controlled by a Raspberry Pi sub-server unit, which is responsible for

logging data and passing control instructions to the microcontroller/wifi module unit according

to policies set by the central server. The highlighted sections in figure 4.1 are the modules that

were worked upon over the course of this project.

5

Chapter 5

Design

5.1 Overview

Central server

Sub-server

control data

Figure 5.1: Higher level control modules of the building management system

The higher level control of the building management system is carried out by the central server in

conjunction with various sub-server units managing their own group of microcontroller devices.

The details of the central server and the sub-servers are given in the following sections.

5.2 Central server

The central server of the system is a software implementation only. There are no specific

hardware requirements for the same. The server is implemented in such a manner so as to be

able to provide interfaces to both the sub-server devices using a REST API and also to system

administrators by way of a GUI. If required, the central server could be on the cloud. The server

can be broken down into two main modules, the frontend and the backend. A proof of concept

implementation of the backend was worked upon over the course of this project.

6

5.2.1 Design specifications

Frontend

The frontend of the central server consists of a hierarchy of web pages created using HTML/

CSS/JavaScript/jQuery and the Bootstrap framework. This provides the GUI which can be

used by system administrators for overall analysis/control of the system.

Backend

The backend of the central server consists of a web application created using the Python web

framework Django.

5.2.2 Design choices

There are various design choices that had to be made in order to create a cohesive and well-

structured central server for the BMS project. The central server is implemented as a web

application. The choice of a web-application was made keeping in mind the advantages of web

applications over traditional desktop applications -

• Easier deployment - The application does not need to be individually deployed to any

client machine. The client machine only requires a functioning web browser to access the

system.

• Maintenance - System maintenance is vastly easier as all updates and bug fixes need to be

introduced at the server end only. In the same manner, regular updates are also easy.

• Platform independent - This was the major reason in favour of using a web application.

The server implemented as a web application provides complete functionality to clients

running any OS.

• Faster development process - By using a web application, users access the system by

way of a web browser. This creates a uniform environment across platforms. While user

interaction with the application needs to be thoroughly tested on different web browsers,

the application itself needs only be developed for a single operating system. There is no

need to develop and test it on all possible operating system versions and configurations.

This makes development and troubleshooting much easier.

• Scalability - Being independent of hardware configurations, web applications are easily

scalable. It is possible to scale the system with growing I/O points or number of client

instances.

7

5.3 Sub-server

5.3.1 Design specifications

The sub-servers are individual Raspberry Pi units running a Debian based Linux OS distribution

called Raspbian. These devices are connected to the central server using a wired Ethernet

connection and each unit manages up to 20 AVR microcontroller units over a WiFi interface.

The Raspberry Pi devices host a web server which provides various functionalities.

5.3.2 Design choices

The choice of using a Raspberry Pi device for the sub-server was made considering the following

points -

• Ease of deployment - Due to the small size of the device, it is easy to deploy unobtrusively

in extremely small spaces such as wiring closets and channels, where power supply and

Ethernet cables are available.

• SoC - The Raspberry Pi provides us a complete system on chip ie. it integrates all the

components of a computer on one single chip. This micro-computer does not require any

additional chips for its functionality, with a built-in Ethernet interface.

• Remote access - The Raspberry Pi devices can be accessed by an administrator using SSH

over the network for the purpose of updates/maintenance/remote debugging etc. There is

no need to obtain physical access to the device which would be difficult in most cases.

8

Chapter 6

Implementation

6.1 Central server

6.1.1 Description

The central server is a Django web application which uses a time-series DBMS. The frontend

part of the web application is done using HTML/CSS and bootstrap.

6.1.2 Functionality

The central server has been coded as a stand-in for a more comprehensive implementation in

the future. Presently, it consists of a barebones Django server with little functionality apart

from receiving data files from and sending configuration files to the sub-server units.

6.2 Sub-server

6.2.1 Description

The Raspberry Pi units serving as sub-servers run a Django based web application which serves

a REST API. This is utilised by both the ESP devices and the central server which communicate

with the device using HTTP messages. This is further explained in the next section. Over the

course of this project, the entire Django server was rewritten to provide enhanced functionality

while being lightweight. The database system being used to store client data was moved from a

MySQL database management system to a flat file system.

9

6.2.2 Functionality

For ESP device

Communication taking place between sub-server devices and the ESP devices follows the client-

server model in case of data logging, whereas in the case of setting configuration, the sub-server

(Rapberry Pi device) initiates a message to the client (ESP device) without a prior request from

the client.

• Data logging - The sub-server device provides a REST API method for ESP devices to

log data. The ESP device makes an HTTP POST request to the Raspberry Pi sub-server,

which processes the attached data and stores it in a file. This data is stored using the ESP

MAC addresses and the HTTP sub-server timestamp as keys. Thereafter, the sub-server

sends a confirmation message back to the client.

• Setting configuration - The ESP devices also receives configuration messages from the

sub-server units. These messages contain the register values which will be written to the

microcontroller for AHU control.

The sub-server extracts the ESP devices’ MAC address from the configuration file, along

with the data to be sent to the client. It then makes an HTTP GET request to the ESP

device containing the data.

For central server

• Receive configuration file - The sub-server device acts as a client for this method, used by

the central server to transmit a json file to the sub-server using an HTTP POST message.

• Send logging data - The Raspberry Pi device sends the data log to the central server

using HTTP POST message containing a log file at a fixed time interval. This enables the

deletion of the files at sub-server end, freeing up valuable memory resources.

10

Figure 6.1: Flowchart of data logging functionality provided by Raspberry Pi sub-server tomicrocontroller devices

11

Chapter 7

Working Prototype

The entire project stack will be demonstrated by a proof-of-concept prototype. The microcon-

troller functionality will be implemented in software similar to the central server for the purpose

of the demonstration. The Raspberry Pi system used will be set up remotely and accessed using

SSH. It will run a Django server providing the following features -

• Downstream port for the microcontroller to post data

• Python script executed via a shell script setup as a cronjob to send the collected data to

the central server

• Upstream port for the central server to post a configuration file containing IP addresses

of the clients under control of a Raspberry Pi sub-server

• Python script executed via a shell script setup as a cronjob to send control commands to

the microcontroller as directed by the central server

The central server will be setup as a separate Django server providing the following features -

• Python script prompting the user for the IP address of and data to be sent to a microcon-

troller client, which will be formatted into a JSON file and sent to the Raspberry Pi sub

server

• Downstream port to receive collected client data from the Raspberry Pi sub-server

12

Bibliography

[1] Django. Django Documentation, 2014.

[2] Doxygen. Documenting the code. Doxygen, 2016.

[3] Get Bootstrap. Getting started with Bootstrap, 2016.

[4] Guides, G. Mastering Markdown. Github, 2014.

[5] Kumar, D. Best Practices for building RESTful services. Infosys, 2015.

[6] Python. Base HTTP Server, 2016.

[7] Reitz, K. The Hitchhiker’s Guide to Python. O’Reily Books, 2016.

13