Smart lecture room for smart campus building automation system

List of abbreviations BAS Building Automation System BS Building Server FTDI Future Technology Devices International GPIO General Purpose Input Output GPU Graphical Processor Unit G

Smart Lecture Room for Smart Campus

Building Automation System

Kien Tran Pham Thai

Master thesis submitted under the supervision of Prof Dr Ir Martin Timmerman

In order to be awarded the Master’s Degree in

Master thesis submitted under the supervision of Prof Dr Ir Martin Timmerman

In order to be awarded the Master’s Degree in MSc in Electronics and Information Technology Engineering

Academicyear

2014-2015

Abstract

In the recent years, the terms of “Internet of Things” and “Smart Building Automation System” come into practical implementations from a hot topic for researches and developments Beyond the concept of every facilities or appliances in your apartment or office can be controlled remotely, as an automated entity, such system is now required to be intelligent The intelligence include an adaptive operation with context awareness, energy efficiency, and comfort living experience However, it is difficult to realize such complicated systemsdue to a gap between a high levels of abstract level in expectations to an actual operational devices, which is called design flow

The purpose of this work is to realizea Smart LectureRoom, from a classical campus lecture room,as

a complete solution for both building manager and user During the development, the design process for this particular system is constructed The realized system will be analyzed to have better improvements in the future

The development process is based on a general embedded system design process with adaptions in context of the particular Smart Lecture Room The thesis grows in five stepsof progression Firstly, the design concepts are defined and follow withan investigation typical lecture rooms in VUB - Vrije Universiteit Brussel campus This investigation deliversa picture of the real installation of infrastructure The first stepcontinues with findings of problems of the invested rooms to usefor later definition of requirements of overall system After that, a general architecture for the smart room, which contains information about the development platforms, is proposed and lateris divided into subsystems for simplification Secondly, an actual design and prototyping of the conceptual smart room in term of software on specified hardware components is performed on the distributed subsystems Thirdly, the subsystems are integrated back in a complete system for further evaluations and analyses Fourthly, the results is presented and discussed Finally, the thesis ends with a summarization of the work and potential future improvements

As the results, the prototyped system is not only capable of providing automation control features for the facilities of the class room from a centralized control interface, Room Controller, with high a resolution GUI touch screen The facilities of the room are managed by the Room Nodes There are 5 Room Nodes: Main Switch Node, Dimmer Node, Sensor Node, Door Lock Node, and Window Node The nodes will both receive control actionsand send data toward the Room Controller For example, the user can switch the states of lights remotely or manually, dim the lights, read environmental information of the room, open the main door with his/her RFID tags, check if the windows or door is opened or closed, and even be alerted when any of the windows is broken The prototyped system also elevatethe room up to a higher level with intelligent features The intelligence provides an automatic reduction of wasted energy with occupancy-based mechanism In addition to that, besides the autonomous operations, to offer management features, a Building Server connects individual smart rooms together for monitoring purposes The Building Server has images of the rooms in the building An image contains the states, values of all facilities in the room, and be updated with real-time changes from Room Controllers As such, the manager will be able to monitor the equipment of every single room in the campus building

Keywords: Smart Lecture Room, Smart Building management system, Smart Cities, Real-time

embedded system, MVC JavaFX Embedded system, Multitasking system, ZigBee two ways

communication

Acknowledgements

First and foremost, I would like to express my deep gratitude to my promotor Prof Dr Ir Martin Timmerman for his enormous support, encouragements, and guidance since I had started the Master Thesis with zero knowledge in the field Approved by the professor from 15th September of

2014, Prof Martin Timmerman offered me a cozy work space with full access to the devices for me

to develop my embedded design skills Gradually, with his talents in both of his expertise and business experience, I had received his motivation, advice, suggestion to not only develop my thesis

in a professional way but also in a very business oriented manner A long with funding me for the equipment, he also always available to comment on my progress reports, solve the troubles, and revise my work with his immense knowledge

Besides my promotor, I would like to send my sincerely thanks to the crew of Embedded System Lab: Long Peng, Fei Guan, and Dr.Hasan Fayyad-Kazan, for the supports during the development of my thesis with their insights knowledge on technologies, devices supply and IT infrastructure

I also would like to express my thankful attitude to all my friends in Belgium and my Vietnamese friends here in Belgium and back in Vietnam for their encouragements, blesses, even just chitchats

to help me overcome the difficulties in my study abroad

Last but not least, I would like to thank my family: My parents: Tran Duc Tin, Pham Thi Van Ha, my younger sister: Tran Pham Kim Ngan, my brother in law: Dinh Ngoc Minh, and my new born nephew, for giving me infinitive source of motivation and backing me up with up and downs in my life

Table of contents

Abstract 1

Acknowledgements 4

Table of contents 6

List of abbreviations 8

List of figures 10

1 Introduction 14

1.1 Motivation and Objective 14

1.2 Related works 14

1.3 Scope and Roadmap 19

1.4 Methodology 20

2 Pre-prototyping process 22

2.1 Design concepts 22

2.2 Field investigation and Problem identification 24

2.2.1 Field investigation 24

2.2.2 Problems identification 26

2.3 System requirements 26

2.4 System architecture 29

2.5 Subsystems distribution 32

2.5.1 Introduction 32

2.5.2 Network model 33

2.5.3 Data model 35

2.6 Summary 38

3 Room Nodes 40

3.1 General description 40

3.2 General architecture 40

3.3 Main Light Switch Node 42

3.4 Dimmer Node 46

3.5 Sensor Node 48

3.6 Door Lock Node 51

3.7 Window Node 53

3.8 Summary 55

4 Room Controller and Building Server 56

4.1 Room Controller 56

4.1.1 Description 56

4.1.2 Hardware architecture 56

4.1.3 Software architecture 57

4.1.4 Model 57

4.1.5 View 58

4.1.6 Controllers 59

4.2 Building Server 65

4.2.1 Description 65

4.2.2 Architecture 66

4.2.3 Functionalities 66

4.3 Summary 67

5 Post-prototyping process 68

5.1 System integration 68

5.2 System evaluation and Analysis 68

5.2.1 Functionalities evaluation 68

5.2.2 Analysis of Room Nodes 69

5.2.3 Analysis of Room Controller 71

5.2.4 Cost evaluation 74

5.3 Summary 75

6 Results 77

6.1 Prototyped devices 77

6.2 Graphical user interface 78

6.3 Summary 80

7 Conclusions 81

8 Future works 83

9 References 85

List of abbreviations

BAS Building Automation System

BS Building Server

FTDI Future Technology Devices International

GPIO General Purpose Input Output

GPU Graphical Processor Unit

GUI Graphical User Interface

HBAS Home-Building Automation System

JSON JavaScript Object Notation

JSSC Java Simple Serial Connector

MCU Micro-Controller Unit

MVC Model-View-Controller

PLC Programmable Logic Controller

RC Room Controller

RF Radio Frequency

RFID Radio-Frequency Identification

RTOS Real Time Operating System

SBS Smart Building System

SOA Service Oriented Architecture

WSN Wireless Sensor Network

List of figures

Figure 2: Services model of a proposed Building Automation System 17

Figure 8: The transformation of a conventional lecture room to a smart room 23 Figure 9: The management interface of the building gathers all individual Smart Lecture Rooms with

Figure 10: The invested building D of VUB Campus with 6 factors for consideration in each of the

Figure 15: The system should serve three different types of actors 27

Figure 19: Overall system architecture for the Smart Lecture Room 30

Figure 21: There are 7 subsystems in total, after the subsystems distribution 33 Figure 22: The coordinator (Room Controller) and its connected nodes (5 Room Nodes) 34 Figure 23: Addressing scheme in a star topology with LQIs (Link Quality Indicator) 35 Figure 24: Static local IP addresses of Room Controller and Building Server 35 Figure 25: Format of exchanging wireless data payloads between Room Controller and Room Nodes

36

Figure 28: The partial architecture of the Smart Lecture Room system 40

Figure 30: Generic Multi-tasking, two ways, enhanced reliability communication for ChibiOS on

Figure 33: User can control the light system either by using the Room Controller interface or the

Figure 34: The particular architecture of the Main Light Switch Node 43 Figure 35: Inherited multitasking architecture for the Main Switch Node 44 Figure 37: The difference in patterns of collected values from sensor with and without the presence

Figure 39: Sequential diagram of communication between actors (User, Room Controller GUI), and

Figure 41: Inherited multitasking architecture for the Dimmer Node 47

Figure 43: Sequential diagram shows the communication between the Node and the Room

Figure 45: Inherited multitasking architecture for the Sensor Node 49 Figure 46: The operations of the Motion tracking task to send mail letter to the mailbox 49 Figure 47: The operations of the Light level tracking task and Temperature tracking task to send mail

Figure 48: Sequential diagram shows the communication from the Sensor Node to the Room

Figure 50: Inherited multitasking architecture for the Door Lock Node 51 Figure 51: The operations of the Door state tracking task on the left, and the RFID scanner task on

Figure 52: The sequential diagram shows the exchange of formatted messages between the Room

Figure 54: Inherited multitasking architecture for the Window Node 53 Figure 55: The operations of the Glass breaking task (on the left) and Window 1 state tracking task (in the middle) and Window 2 state tracking task (on the right) 54 Figure 56: The sequential diagram shows the exchanging formatted messages between the Node

Figure 59: Entity Relationship Diagram of the local database of the Room Controller 58 Figure 60: The Controllers consist of 10 controllers, which are categorized into three main groups 59 Figure 61: Sequential diagram of the controller in dealing with the messages from Main Light Switch

Figure 62: Sequential diagram of the controller in dealing with the messages from Sensor Node 61 Figure 63: Sequential diagram of the controller in dealing with the messages from Door Lock Node 62 Figure 64: Sequential diagram of the controller in dealing with the messages from Window Node 63

Figure 70: The usage of Flash memory of the Arduino MEGA 2560 in Room Nodes 70 Figure 71: The SRAM consumption of the Nodes with their multitasking code architecture 70 Figure 72: Memory performance of the Raspberry Pi from start up 71

Figure 75: SD Card data occupation 73 Figure 76: Range test for XBee communications between Room Nodes and Room Controller 74 Figure 77: The overview of cost per components over total cost of all the five Room Nodes 75 Figure 78: The costs of subsystems compare to total system cost 75

Figure 81: Light system tab of the SLR to offer controls on lighting system 78 Figure 82: Environment sensing tab of the SLR to offer overview of environmental information 79 Figure 83: Access Control tab of the SLR to show current state of main door and entered users 79 Figure 84: Security tab of the SLR to offer current states of two windows frame and its glass state 80 Figure 85: The received JSON packets in back end Building Server 80

1 Introduction

This chapter delivers motivation and objective of the thesis Moreover, the chapter also equip readers with current situation of researches in the domain Then, the chapter presents research scope and the construction of contents of the thesis will be presented The chapter ends with a design methodology

1.1 Motivation and Objective

Current technological world is witnessing a new evolution of Internet of things from a hot trend to a common interest of both university research projects and market providers for practical applications Among those applications, Building Automation System (BAS) standouts with not only has capability of serving many applications but also provides possibilities to save significant amount

of wasted energy Under the hood, each system is driven with a combination of hardware and software platforms to form a complicated embedded system With an implementation of Micro Controller Unit (MCU) and more advanced software solution,Real Time Operating System (RTOS), the system reachesthe state of a Smart Building Automation System (SBAS) The smart system allow user to take direct command and adapt themselves to environmental context As an electronics engineering student, such system is an infinite source of motivation

The Master thesis proposes a complete solution for Smart Building Automation System, Smart Lecture Room, to bring it to life in real devices from defined abstract requirements The Smart Lecture Room offers both automation features and smart saving feature The thesis provides a good material for generalization of the design process and metrics to measure future enhancements

1.2 Related works

Review 1: The definition of the zone management leads to division of a building into room scales

In [1], the group of authors mentions about HBAS term (Home and Building Automation System) where both systems is grouped together in one treatment However, the paper still clearly draw the distinctive objectives betweenthe two The HAS should provide comfort for users that is transparent

to them Meanwhile, the BAS provides the services in the consideration of energy usage efficiency and economical target In this sense, a BAS can borrow or take advantage of HAS development achievements

In order to cope the complexity of a building system, which contains many services and devices, a solution is carried out by Wolfgang Kastner, Georg Neugschwandtner, Stefan Soucek, and H Michael Newma by definitions of control zones [2] In more details, due to the observed temperature differences between locations in a building, rooms are categorized in zones for conditional optimization/control strategy for that unit area

The zone division approach also discussed in [3] where the term of smart spaces is introduced in the SETH (Smart EnvironmenT Hierarchy) AGENT ARCHITECTURE as:

Figure 1: Hierarchical arrangement of smart spaces

The definition of zones narrows down the scale of the work of massive system to manageable system

Review 2: Real time system concept against real time operating system implementation in smart embedded system

Moving into the application of WSN (Wireless Sensor Network) for the real time monitoring system, Woong Hee Kim, Sunyoung Lee, Jongwoon Hwang proposes a solution using ZigBee network to monitor energy and control devices in home automation scale [4] The system is also scalable to building systems The system contains a WSN ZigBee, Gateway, with both web, and smartphone user interfaces This work brings intelligence to energy management in building and uses only ZigBee The system managements level walk down to individual devices including toggling the state of devices and outlets However, the application of the term real-time only implies the method of information retrieving and not for the installation of any real time operating system on the MCU (Micro Controller)

In the light of the work from a master thesis in [5] on energy consumption management for a building system, Wisam Nader introduces a system called RPTM (Real Time Monitor)/ZPM The proposed system has capability of reporting energy statuses at moments in time, location of individual loads with a database and a friendly data visualization solution The system useswired serial to link from Measurement, Processing and Communication Unit (MPCU) (current and voltage transducers) to MPDC (Main Processing, Display and Communication) The workalso mention ZigBee technology but not used The devices in the system are identified by addresses For software control logic, the system uses only interrupt handler but not the Real Time Operating System (RTOS) This is

a simple software solution but less flexible when dealing with complication in handling multiple peripherals

From [4] and [5], the real time terms are again just the description of data collection methods instead of the application of actual RTOS

Review 3: Service-Oriented Architecture (SOA) is an ideal approach for architecture of large scale smart system

In [6], SOA for industrial communication of smart embedded systems is presented by Franqois Jammes and Harm Smit The paper introducesa basic definition of a SOA system: “A service-oriented

systems” In other words, a SOA system must be able to perform both features: independently work

as an autonomous system and cooperatively work with other systems Furthermore, the two authors also introduce operations and characteristics for a device in the network such as: addressing scheme (uniquely defined), discovery strategy (new device join network), description, control, event and presentation

In [7], Long Ngo introduces SOA architecture for network of appliances or smart home In the paper, the definition for SOA is deducted from a comparison with a traditional SDA (Server Centralized Architecture) The author mentions SDA system with drawbacks in interoperability, scalability and extensibility In addition to that, to implement the interoperability, users must define the scenarios for server by themselves The server side receives more burden when the system delivers the supports for third party technologies and protocols According to Long Ngo, SOA can provide a better interoperability This architecture enables different devices in different technologies can communicate in one common language and be more adaptable to the association of new joining devices There is an example to demonstrate a typical SOA scenario without any immediate server Although, except the interesting example of a scenario, there is no actual system is built of designedin the paper Long Ngo also addressed several issues of non-centric architecture like pure SOA must cope:

 Network failure adaption, no guarantee for proper operations of appliances

 Conflict occurs if two system both speak to the other at the same time

 Network grows, communication overhead due to the introduction of inter-node communications

 Price burden on the complexity of the device

Figure 2: Services model of a proposed Building Automation System

As shown on the figure, each subsystem works independently with its service and centralized at the Room-/Building-Controller This implementation will significantly eliminate the drawbacks of pure SOA system that was discussed by Long Ngo in [5]

In the paper, the definition of workflowissimilar to the definition of scenario,which expresses the

interaction among subsystems There is an example of heating subsystem with both set point tracking using sensor data and external source of weather forecast

The works are good guidance for design with the services model, SOA node construction from sensors and actuators but not flexible due to wiring and there is a limitation of no demonstration Review 4:The selection of ZigBee as communication technology in practical design

Previously, ZigBee was mentioned as a candidate for wireless home communication network in [4] [5]

ZigBee technology, as one of the reviewed wireless technologies in [9] standouts among the counterparts with its expensive characteristics The technology ensures not only a sufficient of

communication functionalities but also lower the device cost and power consumption

In [10], ZigBee is also one in the collection of wireless technologies for home system The authors of

the paper defines a term of Context-Aware Computing where the devices are not only scattered

around and works autonomously but also be aware of user actions and environmental dynamic

adaption Furthermore, the paper givesa definition of Environmental Control with a description of a

system that makes use of both from internalthermostats, humidity, airflowinformation and external sensors such as thermostats, humidity, sunshine, wind speed meter etc

Review 5: The related works on design of smart devices

In [11],a real time mechanism is applied in a home automation system The two researchers have built a system with a central microcontroller is an Arduino board,which runs the scmRTOS (Single

based smartphone The system employs sensors (light and temperature), actuators (relays), and LCD display module This gives an example of a complete node design in both hardware and software dimensions with pursuance of SOA concept

However, the system posts some limitations in communication technology and the scalability In terms of technology, the designed system relies on the Bluetooth communication medium and only communicate with the Android phone In other words, this model is point to point communication with limitations of Bluetooth technology and vulnerable to security faults The need is having a more extendable system with numbers of objects that can smoothly talk to others and more secured

wireless communication technology

In [12], Christin John Thomas delivers a complete design of a building electrical intelligent controller using low-cost Atmega8 AVR controller The controller can communicate with mobile devices using wireless GSM From the user point of view, user can monitor, configure, and switch the states of the controlled devices

This work is a valuable reference for the design of autonomous nodes or subsystems in the building system at low cost demand The node satisfies one of the two basic requirements for a SOAarchitecture, the autonomous operation with sensors, actuators and LCD display In addition to that, the node consumes low power with battery or solar panel

Figure 3: Hardware components of a node

Nevertheless, in the work of the Master thesis, there is a need of ZigBee technology as communication medium among devices instead of GSM In order to complete the system with SOA architecture, it needs to havemultiple of nodes with interaction capability

In [13], Guangming Song presents a design of network monitoring system for home automation The proposed system uses open communication protocols ZigBee The system is centered at a base station as a home server, and surrounded with wireless sensor nodes The topology is mesh A node

is driven by a WSN operating system, TinyOS The base stations has Bluetooth interface to allow Bluetooth access from PDAs, and smart phones This also play the role of a gateway for wireless and Internet The base station is then wired with a PC that provides the home server withoutside Internet access

The demonstration of the node with RTOS and ZigBee technology is an advanced model for the end devices

In [14], the group of authors proposes a home automation system that is bases on ZigBee network The aims of the system are: novel, stand alone, low-cost and flexible The low cost, flexible and scalable characteristicssupport multivendor by enabling the gateway to support both WiFi, ZigBee and Internet

System model:

 Home Gateway: WiFi + ZigBee, database

 Home Automation Devices: Light Switch, Radiator Valve, Safety Sensor (temperature, carbon

monoxide, flame, and smoke sensors)

In combination with [13], the works offer a full setup of an advanced system with potential of being smart and ensures scalability However, the system showsa lack of proof for interoperability among home automation technologies

The Euro Commission has funded a large number of projects in smart building systems in [15] This is

a source of reference materials about how a project about building automation can be done in real pilots and actual device installations

The information from the accessed materials will be a good start for the later development of the thesis

1.3 Scope and Roadmap

The concept of Smart Building Automation System covers a large fields of applications, which regards the usages of the building itself For example, university campuses, commerce offices, apartments, hospitals and so on The thesis limits the scope in the context of a university campus to

avoid complexity and take advantage of available accessible facilities in host University, Vrije Universities Brussel In the chosen campus, once again, the scope is narrowed down to a

modernization of a lecture room, which can be found everywhere in the campus At this level, the lecture rooms will be analyzed to point out the common characteristics, limitations and possible

improvements to be smarter Furthermore, the realization process stops at prototypingphase

instead of going further to manufacturing or commercialization phase During the realization process, the thesis only focus on the software development aspect

The contents ofthe thesis expand in 8 chapters The thesis begins with Chapter 1 to deliver to readersan introduction about the work of design a Smart Lecture Room

Chapter 2 givesinformation about design process This is where concepts of the design, field investigation, and, problem identification are mentioned Further on, this chapter provides a high level information about the requirements, architecture platform, and how the system can be broken in smaller subsystems to simplify the design process

In Chapter 3 and Chapter 4, prototyping process of the subsystems are described in details as the

Chapter 5 shows how the subsystems can be integrated and evaluated

Chapter 6 discusses results of prototyped Smart Lecture Room to the readers

Chapter 7 sums up the work withconclusions

Lastly, Chapter 8 proposes further improvements of the work in the future

1.4 Methodology

To obtain the Smart Lecture Room, the development process mainly based on general embedded system design process[16] to have a system from a conceptual model to real devices:

Figure 4: General embedded system design process

The general design process posted disadvantages regard the complexity of the design and reach out

of scope of the thesis, to the phase of manufacturing To have a more appropriate design process for the Smart Lecture Room, an adaptive process is proposed

The adaptive design flow starts with a definition of Design concept in the chosen scope of the Smart Lecture Room The room is a typical room in VUB campus The Research phase in the next step will investigate the current situation of equipped facilities of the room for later formation of system requirements The Subsystems distribution and design step is based on the divide and conquer strategy This is where the whole complicated system is divided into subsystems After that, the phase of Subsystems prototyping and debugging for the subsystems takes place At the end, the subsystems iare integrated before tests and evaluations

Figure 5: Smart Lecture Room design process

The progression of later chapters will discuss the methodology in more details

Smart Lecture

Room Design

concept

Research and Requirements identification

Subsystems distribution and design

Subsystems prototyping and debugging

Subsystems integration

System Test and Evaluation

2 Pre-prototyping process

Following the results from the preceded chapter for the design plan, this chapter explains in details the realization process of the Smart Lecture Room from a basic concepts to the division of subsystems

2.1 Design concepts

Previously in section 1.3, the problem is narrowed down from many types of building to the lecture room

Figure 6: The Smart Lecture Room in context of Smart Buildings

In context of a campus building, a conceptual Smart Lecture Room splits itself into smaller models as the divide and conquer strategy This is an early step to support later subsystem distribution phase Each of the rooms is a combination of Room Controller and a set of Room Nodes (or Nodes) The Nodes indicate under control facilities or end devices

Figure 7: The high level components of a Smart Lecture Room

The coverage of the system on facilities defines the degrees of modernization of aparticular room In other words, the more presences of the Nodes, the more objects in the room are available for system to control The system would like to provide largest coverage as possible in limited time and resourceof the thesis

Lecture Room Campus Building Buildings

Room Controller

Room Node 1

Room Node 2

Room Node 3

Room Node 4

Room Node 5

After dividing the whole system into Room Nodes, the next step is the determination of design orientation to convert a regular room to an advanced smart entity

Figure 8: The transformation of a conventional lecture room to a smart room

From the lecture room point of view, the transformation of the room begins with anexisting infrastructure of a typical lecture room The infrastructure is then investigated, analyzed and added with automation features The automation features allow the users, from one centralized interface can interact or control the system To equip the automated room with the term of smart, more intelligent features are added The intelligence enables the room to have its own decision on its controlled Nodes This is important to save energy when no presence of human control in the room The objective of the thesis is not only to make a room to be smart for usersconnect all the smart rooms in the building in one management interface for building manager These are the responsibilities of the management features

To allow the management features, the design uses the concept of the Service Oriented Architecture (Section 1.2) Following the concept, each of the Room Controller has their own services and can provide themthrough a connection with outer system, Building Server The services here are the status reports or even commands to control certain objects in the room For example, a room provides a service for viewing the state of its light bulbs are on or off, or another service for the Building Server to toggle state of every single ones

The management features is enabled when all the room connected together at one management interface Every room in the building will have the SOA services at its gateway (the Room Controller)

to advertise to the Building Server The Building Server will use the services for monitoring or controlling purposes

Lecture room facilities

Automation features

Inteligent features

Management features

Figure 9: The management interface of the building gathers all individual Smart Lecture Rooms with its own services

2.2 Field investigation and Problem identification

Figure 10: The invested building D of VUB Campus with 6 factors for consideration in each of the rooms

Building server

Smart Lecture Room 1 and SOA gateway Smart Lecture Room 2 SOA gateway

Smart Lecture Room n SOA gateway

Lecture room

Dimension

Light system

Window ventitaing

Heating

Safety and Security

As the results,the collected information reveals common characteristics of the visited rooms However, for simplification, only three out of six aspects will be used for later system development

In term of the measured dimensions, on average most of the room have the floor area is approximately:48 – 53.25m2 The facilities in each of the room is categorized as bellow:

For the lighting system

Figure 11: The light system in the lecture rooms

In general, there are three groups in the lighting system:

 Group 1: Chalk board lighting panel to light up the board This panel has two main switches

and have only toggle states

 Group 2: Presentation lighting group The group handles the brightness of lights for presentation lecture This group is controlled by one dimmer switch

 Group 3: Common lighting group The group lights up the rest of the room with another dimmer switch

The ventilating system:

Figure 12: The ventilation system in the rooms

Group 1 Group 2

Group 3

By locating on second and third floor, the visited rooms uses windows for ventilation For a small rooms, there are two openable window frames As for large room, one more frame is added

The door lock

Figure 13: The radio frequency door lock in the rooms

The door lock system is using the Radio Frequency (RF) key, with the keys database in another building In any case of needing key, renew code, or lost the key, the user have to go to another building to do so The key is valid for user to access certain areas and fixed

2.2.2 Problems identification

The typical rooms manually use electrical components with no presence of automation at any centralized interface Obviously, those regular electrical componentshave no interoperation or communicationat any level The electricityenergy can be wasted from the usage of the lighting system where user leave the room with the lights on until the building opertor visit and shut it off In addition to that, the door lock is maintained with the keys in another building manually The given rights for each key are limited in a hard writen number of rooms to access and no presence of dynamical allowcation For example, to access the certain room in certain time of the day or the year The users have no information about their surrouned environment, which can be a informative knowledge or a major source of reference for control strategies For the case when states of the door or the window needto be checked, for example, the user leave window open after openning for fresh air, there is no solution to have the situation report automaticaly unless paying a visit In hazzard situation, when the windows are broken by either an intruder or hard win blowing, the current primitive infrastructure cannot detect this Besides, the building operators have to visit each single room to have information about the state or control the room facilities instead of having any control interface for a whole building

To solve those problems and even equipe the room with more advanced features, the thesis will later define the requirements, which are based on construction and installations of the current room, for a smarter system

2.3 System requirements

The thesis aims to build a Smart Lecture Room in a campus building environment A smart room should be able to provide the automation and intelligent features on the existing facilities to user on one centralized interface such as:

Figure 14: Proposed features of the Smart Lecture Room

`

Figure 15: The system should serve three different types of actors

On purpose, the system is ready to server three types of actors who have impactsfrom the design process until the regular usages

The developer is the first one who has impact on a system Outcome of the design process depends

Fearures Users can toogle state of the light group 1.

Users perform manual actions on main switch on light group 1 as well

Users dim the light group 2 and 3.

Users can review environmental information.

Users know about the state open or close of the door.

The list of users in the room can be browsed by users.

The state of the windows including open, close, glass broken must be captured and reported.

The door lock is upgraded with RFID tag and key management.

have convenience interface during design phase This contribute significantly to the development time and convenience

The user is the main driven of the system to serve The system should provide to users a central interface to interact with, and also maintain certain basic manual controls in case of malfunction occurs in the automation controller The interface itself must catch up with modern demandsfrom user such as producing high resolution or touch capability The control degrees of the room, which depends on the number of Room Nodes, should be as large as possible to provide comfort living experience to user

The smart room provide both interface for direct users and broadcast its services (Service Oriented Architecture) back and forth with a central server of the building The server of the building should have a large database to store data This allow the building manager to observe up to date statuses

of each room in the building and possible to control them from his desktop

Out of the automation features for user to control, the room also cover security aspect The intruder action or nature storm can cause the damage on the facilities of the room and these actions need to

be detected Furthermore, the room should report additional information about state of the windows and the door This will easy the job of building operators

The user should have an awareness about the environmental information in the room at any moment since they are in This information is not only for user to review but also used for more complicated intelligent control strategies For example, the light level can be measured to display on the GUI but also used for tracking light set point for the light control system Another example of intelligent feature is a capability of perform saving energy with motion-based solution

The design of the Smart Lecture Room implies the scalability of the room to be ready for further adjustments in scales In other words, from the development of the particular Smart Lecture Room, the design is generalized and scalable to different setups, different size and even for the room other thanlecture room

At lower lever to the platform, to ensure the feasibility of a smart system, the solution isan employment of Micro Controller Unit (MCU) At the Room Nodes, each of the devices requires the usage of MCU to host a Real Time Operating System [17] [23] This solution equips the Room Node with certain degree of intelligence to handle the attached sensors or actuators in multitasking environment and also faster the design speed

Figure 16: Construction of a Node

At the Room Controller, where a cooperation of all the Room Nodes takes place, the system must be powerful enough to handle the complicated computation, be handy with a small form factor display,

and consume less power The MCU is not be able to fulfil such complicated tasks but the Micro Processor Unit is capable of The Room Controller should have an interface for user to control the room and anadvanced logical software architecture to drive the hardware platform, MVC architecture [18]

Figure 17: Construction of the Room Controller

In additional to the mentioned platforms, the Room Controller requires the presence of a local database server to save important data

Figure 18: The construction of the Building Server

Last but not least is the place for management features, the Building Server The Building Server is the end point of all the smart rooms in the building and must be powerful to handle the huge data load This relies on the recruitment of a General Purpose Processor in full desktop-based platform The server supposes to provide the GUI for building manager and a backend server to cooperate data flows The back end server should have web services, a large database, and connections with smart rooms

In terms of communication, between the Room Nodes and the Room Controller is the wireless environment for flexible architecture and less installation of wires For the other link from the Room Controller to the Building Server, an Ethernet wire is used to take advantage of previous installed networking infrastructure and possible massive data exchanging

The more detailed information about the chosen platforms will be revealed in the next section of System architecture

2.4 System architecture

From section 2.3, an overall architecture of the system can be defined At this level, the architecture

is a construction of the high abstract level descriptions of the system by summarizing the obtained information so far This architecture provides a broad picture of the system before it going through lower levels of abstraction in design flow Furthermore, the architecture also show the possibility of breaking down to smaller pieces and relationships among system components To satisfy the

MPU InterfaceTouch architectureMVC ControllerRoom

Backend web server

Building Server

Figure 19: Overall system architecture for the Smart Lecture Room

In the figure 19, there are three major types of entities: Building Server, Room Controllers and the Room Nodes, and connections among entities As can be seen, the Building Server connects and manages multiple Room Controller instances In turn, each of the Room Controller can handle multiple instances of Room Nodes Each of the Node in a room can be either connected with actuators or sensors or even both of the two (as controlled objects) The architecture clearly show the scalability of the system The added information here is the technology to enable the links between the entities They are Websocket and ZigBee

Since the architecture is shaped, the reasoning for selection of design platform can be discussed in details in fourdimensions: communication, hardware, software and tool set This gives the readers

an overview of the design platform of the thesis

To enablecommunication among the entities in the architecture, the selected technologies are

Websocket and ZigBee[19] [20] Those two technologies are chosen from candidates based on their superior characters The ZigBee is the most recommended wireless technology for indoor communication in section 1.2 The hardware componentsare available in the lab and can be fast learned with Arduino platformMCU Especially, in API mode 2, ZigBee network supports frame based data exchanging By communicating in frames, the information about the addresses of the sender and receiver is embedded in wireless packets This mechanism wins over a classical implementation

in AT mode or broadcast based communication [21] The API mode 2 be even more important because the system is being situated ina multi-node environment, where the communication from one entity to another should be distinguished from the rest

The other one is a wired technology for HTML 5, which is a combination advantages of socket programming and web HTTP The technology overcomes the disadvantages of classical socket programming method where programmers have to write standalone code In addition to that, Websocket also maintain the capability of serving multiple connection as HTTP Request-Response based protocol A simpleback end server code statements of the Websocket allows the designer to have more time to develop data codec and the GUI of the server instead of messing with low level programming Moreover, this TCP based technology permits massive data transmission at high

speedand real-time streaming, which is the need multiple connections from the Room Controllers to the Building Server

In terms of hardware, the platform for the Building Server (BS) is simple a desktop computer For the

Room Controller (RC), a credit card-based computer Raspberry Pi is chosen to perform computation

of the controller The device is available in the lab and have computation power, connectivity that satisfy all expectations so far The device is chosen also because of its popularity and reasonable purchasing price Due a small size, the Raspberry Pi consumes must less power than a regular desktop computer Moreover, the Raspberry Pi hasa large set of interfaces: HDMI, GPIO, USB, Ethernet, GPU, SD card slot for peripheral connections However, the nature of the MPU architecture is on ARM architecture In additional to that, the device is small then the resource is limited The design process should take those characteristics into account to not overload or jeopardize the device

The hardware platform for the Room Nodes are selected to be Arduino Mega 2560, which is available in the lab as well The Mega 2560 is powerful to host RTOS and complicated-memory-thirsty software architecture This device is well-known in the world of engineer with GPIO for connection to peripherals such as sensors and actuators

Both of the computation platforms for Room Nodes and Room Controller are compatible with XBee module and XBee shield for wireless communication The two devices allow the communication between the Room Controller and Room Nodes The devices can be found in the lab and also easy to buy

In terms of software, the Room Controller with ARM architecture is pre-installed with Java SE 8 for

ARM The developer start making Java application without any extra manual installation The Java SE

is used for programming control logic at back end server To have the front end GUI for the Room Controller, the JavaFXML is used due to its capability of serving headful embedded system (system with GUI) To havea database, the Raspberry Pi uses MySQL Server for local data storing However, the importance here is the selection of proper ARM libraries for the connection and peripheral controls Especially, this becomes a challenge and time consuming in finding proper library to enable the XBee and Websocket connections because the special nature of the ARM architecture The operating system to drive the ARM is a Linux-basedWheezy [24] This operating system is chosen because of its compact, well-optimized for the ARM, and open source

The software solution for the Room Nodes are based on C++ like language for the Arduino Mega MCU The language has best advantages are the simplicity and rapid prototyping In additional to that, the language also support Real Time Operating System library, XBee library for communication, and drivers for sensors and actuators The chosen RTOS here is the ChibiOS, [23] The ChibiOS is selected among its candidates because of simplicity, full RTOS features,a good maintainers, and open source

Lastly, the Building Server uses the Java Oracle Glassfish web server to handle connections toward Building Server, and JavaFXML to provide Graphical User Interface

In term of Tool set, to allow java programing on the Room Controller, NetBeans is used for both

remote developing, and profiling thedevice [25] The developer can remotely access local database

of the RC through the MySQL Workbench tool to design and transfer the data model For the Room Nodes, developer uses the Arduino IDE to program the code and flash to the target device However the IDE isquite simple and not as much as convenient as the NetBeans

2.5 Subsystems distribution

2.5.1 Introduction

For such a complicated embedded system like the Smart Lecture Room, the design process required

to be broken into sub-problems The strategy of divide and conquer helps designer to isolate the problem in smaller pieces Since not have to deal with a whole system at a time, the prototyping process can be faster and possible to distribute the workload among in team members, if have, to shorten the design time

Figure 20: Theoverall system architecture in details

The above figure shows the architecture with more information about the platforms for development As being agreed so far, the system can be categorized in three major types of devices: Building Server, Room Controller and Room Nodes By limiting the development to focus on a lecture room, we only need to design one Room Controller to handle a room and connect it to a Building Server Even so, the lecture room requires a certain number of Nodes to offer smart functionalities From design concept of nodding and expected features in section 2.3, the Room Nodes are: Main Light Switch Node, Dimmer Node, Sensor Node, Door Lock Node, and Window Node.The summarization of all the subsystems can be found at the figure bellow

Figure 21: There are 7 subsystems in total, after the subsystems distribution

However, having the subsystems and the architecture is not sufficientfor the design due to different functionalities of the subsystems and the integration step after prototyping phase As the results, this requires an early conventions for system integration in term of communication model and exchanging data format model The information should be specified at early stage of design flow as a highest level of the architecture.This information guarantees later consistency and success of the integration step This is done in next two sections

2.5.2 Network model

This section providesa picture of a networking model for both of the links for Room Controller – Room Nodes and Room Controller – Building Server For the communication space between the Room Controller and Room Nodes, the links are wireless and use the ZigBee network with 64-bit addressing While in the connection from Room Controller to the Building Server, the link uses Ethernet protocol with regular IP addresses

To have addressing scheme for the Room Controller and Room Nodes, the XBee modules use their serial number with 32bit high part and 32 bit low part As the rule of thumb, the 32 bit of high part

of the serial numbers are similar for all the nodes and the unique identifications lay on the later 32 bit low part

Room Controller

Building Server

Figure 22: The coordinator (Room Controller) and its connected nodes (5 Room Nodes)

In a ZigBee network, the topology requires an employment of a coordinator, which is attached to the

Room Controller The coordinator must be unique and be responsible for coordinating the nodes in

the network The rest of the devices can be defined as Routers (processing and passing messages) or

end devices (only receive messages) In thethesis, the topology contains only Coordinator and

Routers All the ZigBee nodes in the network are assigned with distinctive Node Identifications For

example, the Coordinator is labeled as COOR or the Window node is named as R_WIN_1

Table 1: The list of Nodes with their Serial Numbers (ZigBee addresses)

From the coordinator-routers based relationship, the addressing scheme and topology of the

network can be generalized as bellow:

Figure 23: Addressing scheme in a star topology with LQIs (Link Quality Indicator)

The topology of the network contains six nodes, which corresponds to 5 Room Nodes, and a coordinator, as for the Room Controller On each of the node, a ZigBee address is attached with a 64 bit address Technically, all the nodes can communicate with each other to form a mesh network However, in the thesis implementation, only a star topology is used (the thick bidirectional arrows)

In other words, the Room Nodes communications are centralized at Room Controller without any communication among the Room Nodes themselves.The additional information about the quality of the wireless links are also embedded in the figure as the numbers above each of the links

For the communication between the Room Controller and the Building Server, the static IP addressing scheme is applied as bellow:

Figure 24: Static local IP addresses of Room Controller and Building Server

2.5.3 Data model

Since the addressing scheme for communications is defined, the next step is to decide how data can

be exchanged among the subsystems and in which format For control purpose, the messages must

be in a conventional format to allow the subsystemsto read, decode and verify the data that belong

to their responsibility Similar to the Network model, the formats in this section are divided in two relations of Room Controller – Room Nodes and Room Controller – Building Server As a

Room Controller 10.7.249.4/255.255.252.0

Building Server 10.7.249.2/255.255.252.0

For the exchanging data in Room Controller – Room Nodes, The formatis specified in byte

sequences:

Figure 25: Format of exchanging wireless data payloads between Room Controller and Room Nodes

In the figure, the Room code portion indicates the information about the room including the building code, floor number and room number The Room code for the Room Controller as sender is unique with a length of 4 bytes.The Node type part shows the initial of the node itself in 3 bytes To distinguish between same Node type devices, the Node code filed in 1 byte of integer number is included For different instances of same Node type, the field is increased by 1 Task code field indicates the taskthat issues or targets to receive the data value This field exists due to multitasking context of the software driver of the Room Nodes If there are more tasks that are involved into the information emitting process, the accumulated value will be assigned to the tasks and used to identify the information from or belong for tasks in communication process

Actual data portion is a variation of choices between 1 and 5 bytes of data This part contains actual information that needs to be extracted as real information exchanging,which is away from overheads introduced in preceded information fields The nature of data to send determines the size

of this portion

Examples of data packet for the room 28 first floor in the building K:

 4 bytes data from Sensor Node to Room Controller: K128MSW1 1 [4 bytes of union float

temperature data]

 5 bytes data from Door Lock Node to Room Controller: K128MSW1 1 [5 bytes of RFID Key]

 One Node code but different instances of task codes: Motion sensor: K128SEN1 1 [4 bytes of

data] and Temperature sensor: K128SEN1 2 [4 bytes of data]

 One Node type but different instances of Node code: Data from first Window magnet sensor: K128WIN1 1 [4 bytes of data] and data from second Window magnet sensor: K128WIN2 2 [4 bytes of data]

At the node or at the Room Controller, a 3 rounds check filters outall the data fields to make sure that the received data is correct

For the exchanging data in the other part of the architecture, Room Controller – Building Server,

due to the used technology is Websocket, a TCP based packet format, JSON packets, areused [22]

By default, a JSON object is a simple formatted text data to transport over the Ethernet cable without awareness of the source and destination of the data payload in Websocket technology To have such awareness, the control information should be includedin transported data in each JSON

bytes

object Moreover, JSON objects requireencoder and decoder at both ends of the communication link This can be done with proper third party libraries

Due to the fact that JSON objects introduce overheads on actual data payload, a more complicated JSON object or an increment in number of exchange objects can increase network traffic significantly This is a serious issue when there are many connections from Room Controllers to Building Server at a time and the broadcast nature of the Websocket technology back end server To reduce the bandwidth burdenfor the system at traffic moments, the exchanging data between the Room Controller and the Building Server is divided into two types of objects: Full and Partial JSON objects

The full JSON object contains all information about the room This is sent once to the Building Server

from the Room Controller when the Websocket link is established This object provides a full initial image of the room With the first full image, the Building Server can have a knowledge of provided services of the room and adds it to its management list or database

Figure 26: Elements of a full JSON object

As can be seen from the figure, the object contains three parts including Identification, Control and Data fields In the context where the Building Server (BS) has to manage multiple room instances, the Identification fieldprovides sufficient information about the sender for the BS to classify incoming messages into proper managed rooms The piece information is a set of: ID of the room, its IP address and the destination to the BS The destination field helps to distinguish the direction of data from between RC and BS

The middle part of the item is the indications of the connectivity that the RC is monitoring This include the current states of connections to database, XBee communication channel, Websocket link and the peripheral Buzzer The last part of the JSON object carries the information of the managed services of the Room Controller that wants to inform the Building Server in the Data fields

For regular updates of the services the partial JSON object is used Each of the object keeps the

Control fieldfrom the full JSON object However, only one of the elements that needed to be sent is included in Control or Data fields

Figure 27: Elements of partial JSON objects

The above code snippet shows an example of partial JSON object passing To ensure the identity, the Identification fields is remained in each object The difference is located at Control fields and Data fields The data that have any presence of alternation will be updated only, independently from other to the BS So far, the JSON objects are travelled in the direction from RC to BS to provide monitoring services To have the control actions from the BS back to RC, the more JSON object formats should be added

2.6 Summary

The chapter had presented the very first information about the system from a high level of

abstraction down to subsystems distribution, before the system goes through prototyping process The chather started with design concepts to provide design terms, naming convention and a broad picture of development and integration Later on, from a practical investigation on the VUB campus, the issues of existing infrastructure were addressed and tackled with a proposed requirements for the Smart Lecture Room The chapter continued with critical information about the overall

architecture and selection of development platform Lastly, the chapter ended with a solution for simplicity of design process by dividing the entire system into subsystems and summary of the work

3 Room Nodes

3.1 General description

This is the lowest level of the architecture where control logic are applied to an under controlled objects, room facilities, to automate them There are 5 Room Nodes in total

Figure 28: The partial architecture of the Smart Lecture Room system

The figure shows the detailed partial architecture of the system from the Room Controller to the Room Nodes At this level, the information about the choice of peripherals for each of the Room Nodes is added According to the design purpose, only the Door Lock Node and the Main Switch Node have both sensors and actuators The rest of the Room Nodes have either sensors or actuators for its services

3.2 General architecture

Figure 29: General hardware architecture for the Room Nodes

All the Room Nodes in the system share a common hardware platform The variations depend on the peripherals that are attached to them As can be seen in the figure, the chosen Arduino Mega and the ChibiOS play the most important role in each of the subsystem Besides, a node has XBee shield and its module to perform communication to the outside world To interact with the controlled

Arduino MEGA 2560 Sensor Actuator

XBee Shield + XBee module ChibiOS