1 Số hóa bởi Trung tâm Học liệu – ĐHTN http //www lrc tnu edu vn S Smart Lecture Room for Smart Campus Building Automation System Kien Tran Pham Thai Master thesis submitted under the supervision of P[.]
Introduction
Motivation and Objective
The evolution of the Internet of Things (IoT) has transformed it from a trending topic to a focal point for university research and market applications, particularly in Building Automation Systems (BAS) These systems not only serve multiple functions but also significantly reduce energy waste At their core, BAS integrate complex hardware and software platforms, including Micro Controller Units (MCUs) and advanced Real-Time Operating Systems (RTOS), to create Smart Building Automation Systems (SBAS) This smart technology enables users to issue direct commands and adapt to their environmental context, serving as an endless source of inspiration for electronics engineering students.
The Master thesis presents a comprehensive solution for a Smart Building Automation System, specifically focusing on a Smart Lecture Room that transforms abstract requirements into functional devices This innovative system incorporates automation capabilities alongside energy-saving features Additionally, the thesis serves as a valuable resource for generalizing the design process and establishing metrics for future improvements.
Related works
Review 1: The definition of the zone management leads to division of a building into room scales
The authors in [1] discuss the term Home and Building Automation System (HBAS), highlighting the integration of both systems while maintaining their distinct objectives Home Automation Systems (HAS) focus on user comfort in a seamless manner, while Building Automation Systems (BAS) prioritize energy efficiency and cost-effectiveness Notably, BAS can leverage advancements made in HAS development to enhance its functionality.
To address the complexities of building systems with numerous services and devices, Wolfgang Kastner, Georg Neugschwandtner, Stefan Soucek, and H Michael Newma propose a solution involving the definition of control zones This approach involves categorizing rooms into zones based on observed temperature differences, enabling a conditional optimization and control strategy tailored to each specific 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
Woong Hee Kim, Sunyoung Lee, and Jongwoon Hwang present a scalable solution for real-time monitoring in home automation using a ZigBee network, which effectively manages energy and controls devices Their system integrates a WSN ZigBee and Gateway, featuring user interfaces for both web and smartphone applications This innovative approach enhances energy management in buildings while allowing control at the individual device level, including the ability to toggle states of devices and outlets Notably, the term "real-time" in this context refers to information retrieval methods rather than the implementation of a real-time operating system on the microcontroller.
Wisam Nader's master thesis presents the RPTM (Real Time Monitor)/ZPM system, designed for effective energy consumption management in building systems This innovative solution provides real-time energy status reports, identifies individual load locations through a database, and features user-friendly data visualization The system connects the Measurement, Processing and Communication Unit (MPCU) with the Main Processing, Display and Communication (MPDC) unit via wired serial communication, utilizing current and voltage transducers Although ZigBee technology is mentioned, it is not implemented Devices within the system are assigned unique addresses, and the software control relies solely on an interrupt handler rather than a Real Time Operating System (RTOS), offering a straightforward yet less adaptable approach for managing 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
Franqois Jammes and Harm Smit present a comprehensive overview of Service-Oriented Architecture (SOA) for industrial communication in smart embedded systems They define SOA as a framework that enables systems to operate both autonomously and collaboratively The authors also outline essential operations and characteristics for network devices, including a unique addressing scheme, a discovery strategy for integrating new devices, and features related to description, control, event handling, and presentation.
In his paper, Long Ngo presents Service-Oriented Architecture (SOA) for smart home networks, highlighting its advantages over traditional Server Centralized Architecture (SDA) He points out that SDA suffers from issues related to interoperability, scalability, and extensibility, requiring users to define server scenarios themselves, which increases the server's workload when accommodating third-party technologies In contrast, SOA enhances interoperability by allowing diverse devices to communicate in a common language, facilitating the integration of new devices seamlessly An illustrative example is provided to showcase a typical SOA scenario that operates without an immediate server.
The paper presents an intriguing scenario but does not propose an actual system design Long Ngo highlights various challenges that non-centric architectures, such as pure Service-Oriented Architecture (SOA), must address.
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
Consequently, the usage of native SOA will be a complicated and costly approach As the results, there is a need for a better solution
The article provides a practical overview of Service-Oriented Architecture (SOA) in Building Automation Systems, highlighting that SOA devices are configured with both sensors and actuators, utilizing a wiring bus as the management protocol Each controlled appliance is equipped with its own services, which are illustrated in the accompanying figure.
Figure 2: Services model of a proposed Building Automation System
Each subsystem operates independently with its own service, while being centralized at the Room/Building Controller This design effectively addresses the limitations of a purely Service-Oriented Architecture (SOA) system, as highlighted by Long Ngo in [5].
The article defines workflow in a manner akin to the concept of a scenario, highlighting the interactions between subsystems An illustrative example is provided, featuring a heating subsystem that utilizes sensor data for set point tracking in conjunction with external weather forecasts.
The integration of sensors and actuators in service-oriented architecture (SOA) node construction offers valuable insights for design; however, the rigidity of wiring presents challenges and limits practical demonstrations Additionally, the choice of ZigBee as the communication technology plays a crucial role in enhancing the effectiveness of practical designs.
Previously, ZigBee was mentioned as a candidate for wireless home communication network in [4]
ZigBee technology distinguishes itself from other wireless technologies due to its unique features, offering robust communication capabilities while minimizing device costs and power consumption.
ZigBee is a prominent wireless technology for home automation, as discussed in [10] The authors introduce the concept of Context-Aware Computing, where devices operate autonomously while being responsive to user actions and environmental changes Additionally, the paper defines Environmental Control, detailing a system that integrates internal sensors, like thermostats and humidity monitors, with external sensors such as those measuring sunlight and wind speed.
Review 5: The related works on design of smart devices
In a study, researchers developed a real-time home automation system utilizing an Arduino board as the central microcontroller, which operates on the scmRTOS (Single Chip Microcontroller Real Time Operating System) This innovative device enables communication with Android-based smartphones and incorporates various sensors, including light and temperature, along with actuators such as relays and an LCD display module This project exemplifies a comprehensive node design that integrates both hardware and software aspects while adhering to the principles of Service-Oriented Architecture (SOA).
The current system faces limitations in communication technology and scalability, as it relies solely on Bluetooth to connect with Android phones, resulting in point-to-point communication This reliance on Bluetooth introduces security vulnerabilities and restricts the number of devices that can communicate effectively To enhance functionality, there is a need for a more extensible system that supports multiple devices and utilizes a more secure wireless communication technology.
Scope and Roadmap
The Smart Building Automation System encompasses various applications within buildings, such as university campuses, offices, apartments, and hospitals This thesis specifically focuses on a university campus, particularly Vrije Universiteit Brussel, to simplify the analysis and leverage available resources Within this context, the study narrows its focus to modernizing lecture rooms, which are common across the campus The analysis will identify shared characteristics, limitations, and potential enhancements to make these spaces smarter Additionally, the project will conclude at the prototyping phase, emphasizing software development without progressing to manufacturing or commercialization.
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 critical sections of the thesis
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.
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 traditional design process often faces challenges related to complexity and scope, particularly during the manufacturing phase To enhance the design approach for the Smart Lecture Room, an adaptive design process is recommended.
The adaptive design flow for the Smart Lecture Room at VUB campus begins with defining the design concept The subsequent research phase assesses the current facilities to establish system requirements Following this, the design process employs a divide and conquer strategy to break down the complex system into manageable subsystems This is succeeded by prototyping and debugging each subsystem, culminating in their integration for comprehensive testing and evaluation.
Figure 5: Smart Lecture Room design process
The progression of later chapters will discuss the methodology in more details
Pre-prototyping process
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 a campus building, the Smart Lecture Room concept employs a divide and conquer strategy, breaking down into smaller models to facilitate future subsystem distribution Each individual room integrates a Room Controller with a series of Room Nodes, which represent the controlled facilities or end devices within the space.
Figure 7: The high level components of a Smart Lecture Room
The extent of a system's coverage in a facility indicates the level of modernization of a specific room Essentially, a higher number of Nodes means that more objects within the room can be managed by the system The goal is to achieve maximum coverage efficiently, while optimizing the limited time and resources available for the thesis.
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
The transformation of a typical lecture room begins with an assessment of its existing infrastructure, which is then enhanced with automation features These features enable users to interact with the system through a centralized interface, making the room smarter By incorporating intelligent capabilities, the room can autonomously manage its controlled nodes, significantly reducing energy consumption when unoccupied The thesis aims not only to create a smart room for users but also to integrate all smart rooms within a building into a single management interface for building managers, thereby streamlining management responsibilities.
The design implements Service Oriented Architecture (Section 1.2) to enhance management features, allowing each Room Controller to offer its own services through a connection to the Building Server These services include status reports and commands for controlling various objects within the room For instance, a room can provide a service to check whether its light bulbs are on or off, as well as a service that enables the Building Server to toggle the state of each bulb individually.
The management features become active when all rooms are interconnected through a single management interface Each room in the building is equipped with SOA services at its gateway, known as the Room Controller, which communicates with the Building Server This server utilizes the services for effective monitoring and control of the building's operations.
Figure 9: The management interface of the building gathers all individual Smart Lecture Rooms with its own services
Field investigation and Problem identification
The field investigation aims to identify the characteristics of a typical room within a campus building, specifically conducted at the VUB campus Etterbeek in building D This analysis will inform future developments related to the space.
During the opening hour for classes, 12 rooms are assessed, focusing on six key infrastructure factors: dimensional measurements, existing lighting installations, window configurations, heating systems, safety and security features, and multimedia utilities.
Figure 10: The invested building D of VUB Campus with 6 factors for consideration in each of the rooms
Smart Lecture Room 1 and SOA gateway
Smart Lecture Room 2 SOA gateway
Smart Lecture Room n SOA gateway
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:
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
Figure 12: The ventilation system in the rooms
The visited rooms, located on the second and third floors, utilize windows for ventilation Small rooms feature two operable window frames, while larger rooms are equipped with an additional frame for improved airflow.
Figure 13: The radio frequency door lock in the rooms
The door lock system utilizes a Radio Frequency (RF) key, with the keys database located in a separate building Users must visit this building to renew codes or replace lost keys Each key grants access to specific areas and is fixed in its functionality.
Traditional rooms rely on manual electrical components without any centralized automation, leading to inefficiencies such as wasted energy when lights are left on after users exit Key access to doors is managed manually in a separate building, with rigid permissions limiting entry to specific rooms without the flexibility for dynamic access based on time or date Users lack awareness of their environment, missing out on valuable information that could inform control strategies In scenarios where door or window states need monitoring, such as when a window is left open for ventilation, there is no automated reporting system, necessitating physical checks Additionally, the outdated infrastructure fails to detect hazards like broken windows from intruders or severe weather Building operators must individually inspect each room to gather information or manage facilities, instead of utilizing a centralized control interface for the entire building.
This thesis aims to address existing issues and enhance the room with advanced features by outlining the requirements based on the current construction and installations, ultimately leading to the development of a smarter system.
System requirements
The thesis focuses on developing a Smart Lecture Room within a campus building, designed to enhance user experience through automation and intelligent features This innovative space will integrate existing facilities into a centralized interface, streamlining access and control for users.
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 system prioritizes user experience by offering a central interface for interaction and maintaining essential manual controls for potential automation failures It is essential for the interface to meet modern user demands, including high resolution and touch capabilities Additionally, maximizing the control degrees of the room, which relies on the number of Room Nodes, is crucial for ensuring a comfortable living experience.
The smart room features an interface for direct user interaction while utilizing Service Oriented Architecture to communicate with a central building server This server, equipped with a comprehensive database, enables the building manager to monitor real-time statuses of each room and manage them efficiently from a desktop interface.
The automation features of the room not only provide user control but also enhance security by detecting intruder actions and adverse weather conditions that could damage the facilities Additionally, the system should report the status of windows and doors, simplifying the tasks for building operators.
Users must be aware of the environmental information in their surroundings at all times, as this data serves not only for personal review but also for advanced intelligent control strategies For instance, measuring light levels can enhance the graphical user interface (GUI) while also tracking set points for effective light control Additionally, an intelligent feature like motion-based solutions can contribute to energy savings, optimizing resource use in the environment.
The Smart Lecture Room is designed for scalability, allowing for easy adjustments to accommodate various setups and sizes This versatile design enables the Smart Lecture Room to be adapted for different environments beyond just lecture settings.
To ensure the feasibility of a smart system, employing a Micro Controller Unit (MCU) at the lower level of the platform is essential Each Room Node utilizes an MCU to host a Real-Time Operating System, which provides the necessary intelligence to manage connected sensors and actuators in a multitasking environment, thereby accelerating the design process.
The Room Controller serves as the central hub for collaboration among all Room Nodes, requiring a robust system capable of managing complex computations while maintaining a compact and user-friendly display.
MCU Sensors Actuators RTOS Room
To optimize power consumption, a Micro Processor Unit (MPU) is essential for handling complex tasks, unlike a Microcontroller Unit (MCU) The Room Controller must feature a user-friendly interface for room management, supported by an advanced software architecture, such as the Model-View-Controller (MVC) framework, to effectively operate the hardware platform.
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
The Building Server serves as the central hub for all smart rooms within the building, requiring robust capabilities to manage substantial data loads It utilizes a General Purpose Processor on a full desktop platform to ensure optimal performance This server is designed to deliver a user-friendly graphical interface for building managers while facilitating seamless data flow through a backend system Essential features of the backend include web services, a comprehensive database, and connectivity with the smart rooms.
The communication between Room Nodes and the Room Controller utilizes a wireless environment, promoting flexible architecture and reducing the need for extensive wiring In contrast, an Ethernet connection links the Room Controller to the Building Server, leveraging existing networking infrastructure for efficient data exchange.
The more detailed information about the chosen platforms will be revealed in the next section of System architecture.
System architecture
The overall architecture of the system, as defined in section 2.3, presents a high-level abstract overview that summarizes the information gathered thus far This architecture offers a comprehensive view of the system before delving into more detailed design phases Additionally, it highlights the potential for decomposing the system into smaller components and illustrates the relationships among these elements.
Figure 19: Overall system architecture for the Smart Lecture Room
Figure 19 illustrates three primary types of entities within the system: Building Server, Room Controllers, and Room Nodes, along with their interconnections The Building Server is responsible for connecting and managing multiple Room Controller instances, each of which can oversee several Room Nodes Each Node in a room can be connected to actuators, sensors, or both, serving as controlled objects This architecture demonstrates the system's scalability Additionally, the technologies facilitating the connections between these entities are WebSocket and ZigBee.
The design platform of the thesis can be comprehensively analyzed through four key dimensions: communication, hardware, software, and tool set, providing readers with a clear understanding of the architectural choices made.
To facilitate communication among entities in the architecture, Websocket and ZigBee technologies have been selected for their superior characteristics ZigBee is particularly recommended for indoor communication, as highlighted in section 1.2 The hardware components are readily available in the lab and can be quickly learned using the Arduino platform Notably, ZigBee's API mode 2 enables frame-based data exchange, embedding sender and receiver addresses within wireless packets This approach offers advantages over traditional AT mode or broadcast communication, especially in multi-node environments where distinguishing between communications from different entities is crucial.
WebSocket is a wired technology built on HTML5 that combines the benefits of socket programming with the HTTP protocol, addressing the limitations of traditional socket programming which requires standalone code This technology supports multiple connections like an HTTP Request-Response protocol, enabling developers to focus more on data codecs and server GUIs rather than low-level programming Additionally, WebSocket's TCP-based architecture facilitates high-speed data transmission and real-time streaming, essential for managing numerous connections between Room Controllers and the Building Server.
The Building Server (BS) operates on a standard desktop computer, while the Room Controller (RC) utilizes a Raspberry Pi, a compact and cost-effective credit card-sized computer This device, readily available in the lab, meets all computational and connectivity requirements, making it a popular choice Its small size results in significantly lower power consumption compared to traditional desktop computers, and it offers a variety of interfaces, including HDMI, GPIO, USB, Ethernet, and an SD card slot for peripheral connections However, the Raspberry Pi is based on ARM architecture, which means its resources are limited Therefore, the design process must consider these characteristics to avoid overloading the device.
The chosen hardware platform for the Room Nodes is the Arduino Mega 2560, readily available in the lab This powerful device supports real-time operating systems (RTOS) and complex software architectures that require significant memory Renowned among engineers, the Mega 2560 features GPIO pins for seamless connections to various peripherals, including sensors and actuators.
The Room Nodes and Room Controller utilize XBee modules and XBee shields for seamless wireless communication, enabling efficient interaction between the two devices These components are readily available for purchase and can also be found in the lab, ensuring easy access for users.
The Room Controller, equipped with ARM architecture, comes pre-installed with Java SE 8 for ARM, allowing developers to create Java applications without additional manual installation Java SE is utilized for programming backend control logic, while JavaFXML provides a front-end GUI suitable for embedded systems For local data storage, the Raspberry Pi employs MySQL Server A critical aspect is the selection of appropriate ARM libraries for connection and peripheral controls, which can be challenging and time-consuming, particularly for enabling XBee and WebSocket connections due to the unique characteristics of ARM architecture The system runs on a Linux-based Wheezy operating system, chosen for its compactness, optimization for ARM, and open-source nature.
The Room Nodes software solution utilizes a C++-like language for the Arduino Mega MCU, offering advantages such as simplicity and rapid prototyping This language supports a Real-Time Operating System (RTOS) library, XBee communication library, and drivers for various sensors and actuators The selected RTOS, ChibiOS, is favored for its simplicity, comprehensive features, strong maintenance support, and open-source nature.
Lastly, the Building Server uses the Java Oracle Glassfish web server to handle connections toward Building Server, and JavaFXML to provide Graphical User Interface
To enable Java programming on the Room Controller, developers utilize NetBeans for remote development and device profiling They can access the Room Controller's local database via MySQL Workbench to design and transfer data models For programming the Room Nodes, the Arduino IDE is employed, although it is simpler and less convenient compared to NetBeans.
Subsystems distribution
Designing a complex embedded system like the Smart Lecture Room necessitates breaking the process into smaller sub-problems By employing a divide and conquer strategy, designers can isolate issues, allowing for a more efficient prototyping process This approach not only accelerates development but also enables workload distribution among team members, ultimately reducing overall design time.
Figure 20: Theoverall system architecture in details
The system architecture is divided into three main device categories: Building Server, Room Controller, and Room Nodes, focusing specifically on lecture room functionality A single Room Controller is designed to manage the room and connect to the Building Server, while multiple Room Nodes are necessary to provide smart features Key Room Nodes include the Main Light Switch Node, Dimmer Node, Sensor Node, Door Lock Node, and Window Node, with a comprehensive summary of all subsystems illustrated in the accompanying figure.
Figure 21: There are 7 subsystems in total, after the subsystems distribution
Having the subsystems and architecture alone is inadequate for design, as the varying functionalities of subsystems and the integration process following the prototyping phase necessitate early conventions for system integration regarding communication models and data exchange formats Specifying this information at the early design stage, at the highest architectural level, ensures consistency and success in the later integration phase The details will be elaborated in the following two sections.
This section illustrates a networking model that includes two key links: the connection between the Room Controller and Room Nodes, and the link between the Room Controller and the Building Server The communication between the Room Controller and Room Nodes is facilitated through a wireless ZigBee network, utilizing 64-bit addressing In contrast, the connection from the Room Controller to the Building Server employs the Ethernet protocol with standard IP addresses.
The XBee modules utilize a unique addressing scheme for the Room Controller and Room Nodes, based on their serial numbers, which consist of a 32-bit high part and a 32-bit low part Generally, the high part of the serial numbers remains consistent across all nodes, while the distinct identities are defined by the unique 32-bit low part.
Main Light Switch Node Dimmer Node
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
The Room Controller acts as a unique coordinator responsible for managing the network nodes Other devices in the system are classified as Routers, which process and relay messages, or as end devices, which solely receive messages In this thesis, the network topology consists exclusively of the Coordinator and associated devices.
In a ZigBee network, each node is assigned a unique Node Identification, such as the Coordinator designated as COOR and the Window node identified 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 network topology consists of six nodes, including five Room Nodes and one coordinator serving as the Room Controller Each node is assigned a unique 64-bit ZigBee address, enabling seamless communication among all nodes to create a mesh network However, the implementation in this thesis specifically utilizes a star topology, as indicated by the thick bidirectional arrows.
Room Nodes communicate centrally through the Room Controller, with no direct interaction among the Room Nodes Additionally, the quality of the wireless links is indicated by numbers displayed above each link in the figure.
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
After establishing the addressing scheme for communications, the next crucial step is determining the data exchange methods among subsystems and the appropriate formats To facilitate control, messages must adhere to a conventional format, enabling subsystems to read, decode, and verify their respective data In line with the Network model, this section categorizes formats into two relationships: Room Controller – Room Nodes and Room Controller – Building Server.
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
The Room code section provides essential details about the room, including the building code, floor number, and room number, with a unique 4-byte identifier for the Room Controller The Node type is represented by a 3-byte initial, while a 1-byte integer Node code differentiates between devices of the same type, incrementing for each instance The Task code field is crucial for managing multitasking within the Room Nodes' software driver, indicating the specific task related to data processing In scenarios with multiple tasks involved in information emission, accumulated values are assigned to these tasks to facilitate clear communication and data identification.
The actual data portion consists of a selection ranging from 1 to 5 bytes, containing essential information that facilitates real data exchange, free from the overheads of preceding fields The size of this portion is dictated by the nature of the data being transmitted.
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]
The system utilizes a single Node type with multiple instances of Node code to process data from two distinct window magnet sensors: K128WIN1, which captures 4 bytes of data, and K128WIN2, also providing 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]
In WebSocket technology, a JSON object serves as a straightforward text format for transmitting data over Ethernet, lacking inherent awareness of the data's source and destination To enable this awareness, it is essential to incorporate control information within each JSON payload being transmitted.
Room code Node type Node code Task code Actual data
4 bytes 3 bytes 1 byte 1 byte 1 - 5 bytes object Moreover, JSON objects requireencoder and decoder at both ends of the communication link This can be done with proper third party libraries
JSON objects can add significant overhead to data payloads, increasing network traffic, especially when multiple Room Controllers connect to a Building Server simultaneously using WebSocket technology To alleviate bandwidth strain during peak traffic, data exchange between Room Controllers and the Building Server is categorized into two types: Full JSON objects and Partial JSON objects.
Summary
This chapter introduces a comprehensive overview of the system, progressing from high-level abstraction to detailed subsystems before entering the prototyping phase It begins with design concepts that clarify terminology, naming conventions, and the overall development and integration framework Through practical investigations at the VUB campus, existing infrastructure issues are identified and addressed, leading to proposed requirements for the Smart Lecture Room The chapter also provides essential insights into the overall architecture and the selection of the development platform Finally, it concludes by simplifying the design process through the division of the system into subsystems and summarizing the key findings.
Room Nodes
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 detailed partial architecture of the system, from the Room Controller to the Room Nodes, outlines the selection of peripherals for each Room Node Notably, only the Door Lock Node and the Main Switch Node are equipped with both sensors and actuators, while the remaining Room Nodes are designed with either sensors or actuators to fulfill their specific functions.
General architecture
Figure 29: General hardware architecture for the Room Nodes
All Room Nodes in the system utilize a unified hardware platform, with differences arising from the attached peripherals The Arduino Mega and ChibiOS are crucial components in each subsystem Additionally, each node is equipped with an XBee shield and module for external communication, facilitating interaction with the controlled environment.
XBee Shield + XBee module ChibiOS object, the sensor and actuator are the solution A Room Node can have the presence of both sensor and actuator or one of the two
The Room Node system supports bidirectional communication, allowing each node to send and receive information However, existing examples for the XBee library primarily demonstrate one-way communication While a polling-based strategy addresses this issue, it is inefficient due to the asynchronous nature of communication and the risk of packet loss To enhance functionality and resolve these challenges, the author proposes a multitasking software architecture that enables efficient two-way communication.
Figure 30: Generic Multi-tasking, two ways, enhanced reliability communication for ChibiOS on Arduino MEGA platform
The proposed software architecture solution for MCU nodes incorporates a Real-Time Operating System, specifically ChibiOS, to enhance functionality This architecture enables a Room Node to effectively manage sensors, actuators, and the XBee communication module, while also supporting two-way communication, multitasking capabilities, and improved transmission reliability Each Room Node in the system utilizes the same multitasking software architecture, with modifications tailored to its specific services.
RX Task Packet array byte fr_id; unsigned long start_time; byte data[5]; boolean acked; byte trials; byte id; byte data[4];
The architecture is designed to accommodate multiple tasks, including two fixed tasks: the TX Task (Transmitting Task) and the RX Task (Receiving Task), which facilitate two-way communication between the Room Node and the Room Controller using the physical XBee module Additionally, the system can support more tasks tailored to manage the connected sensors, enhancing the Room Node's functionality To streamline control logic, the RX Task will oversee the management of actuators.
Utilizing a Real-Time Operating System (RTOS) enables a multitasking environment where system tasks manage peripherals, communicate, and share resources efficiently The architecture leverages ChibiOS's software solutions, such as Mailbox and Mutex, to mitigate multitasking dilemmas Tasks responsible for sensor management can send collected data to the TX Task by packaging it into a "mail letter" that includes an ID and data bytes, which is then submitted to the Mailbox The TX Task regularly checks the Mailbox to retrieve this information, adds necessary overhead as outlined in the Data model section, and transmits it over the ZigBee network Additionally, a Mutex is employed to safeguard access to volatile task variables.
To minimize packet loss in poor communication environments, the architecture implements a novel mechanism that improves the reliability of wireless transmissions by monitoring the packet exchanges of Room Nodes This is achieved by storing the data of sent packets in an object array known as the Packet Array, which temporarily retains packets along with essential control information, including "frame_id" and "start_time" (the time of transmission).
The Packet Array utilizes unique frame IDs to identify messages, which are either acknowledged or unacknowledged, along with tracking the number of resends, referred to as "trials." Access to the Packet Array is managed by a separate Mutex, ensuring orderly operations Packets within the array can either be discarded or retained for resending, governed by a time-based monitoring mechanism.
The later part of the section will discuss in detail how the most important and common task TX and
The TX Task involves processing mail letters from the Mailbox to generate payloads for XBee packets, adhering to the data format specified in the Data Model Agreement.
Main Light Switch Node
The Main Light Switch Node is designed to control the primary lighting for the chalkboard area, as referenced in section 2.2.1 for light group 1 Its primary function is to automate the lighting system's control actions within a centralized RC framework Additionally, this node supports manual user inputs via a physical switch, ensuring that the lighting system remains operational even during automation system failures, thereby enhancing overall flexibility.
Figure 31: User can control the light system either by using the Room Controller interface or the wall-mounted button switch
Figure 32: The particular architecture of the Main Light Switch Node
The Node is built on a generic architecture featuring an Arduino Mega and ChibiOS, which enables multitasking and two-way communication through XBee components It incorporates a current sensor to detect the flow of electricity to a light bulb, activated by either a relay or a step relay connected to the main electrical switch User interaction occurs via a wall-mounted button switch, which utilizes the step relay to toggle the light's state.
Relay Current sensor Step Relay
XBee Shield + XBee module ChibiOS
Figure 33: Inherited multitasking architecture for the Main Switch Node
In software architecture, the RX Task receives messages from the Room Controller to toggle light bulb states, while the User Action Tracking task monitors current flow through the bulbs to inform the Room Controller of any state changes This task detects changes without knowing whether they are triggered by the Room Controller or user actions on the switch The operations of the User Action Tracking task are illustrated in the accompanying chart.
The flow chart illustrates the calculation of variations, which arises from the non-linear readings of the current sensor Instead of a simple on/off signal, the sensor outputs data in a waveform pattern.
Figure 34: The difference in patterns of collected values from sensor with and without the presence of current flow
The sensed analog values from the sensor exhibit both DC and cosine wave forms, which complicates the interpretation of whether current is traveling through the line In the absence of current, the sensed values approach a near-zero mean.
Mutex with small variation However, when there is a current flows, a cosine waves are formed with magnitude of 4 at peak when there is a current
To transform raw data into meaningful digital results, knowledge from statistical courses is essential The developer collects 10 samples per period and calculates variations within a window size of these samples This window shifts forward with each new sample, occurring approximately every 30 milliseconds.
Figure 35: Sampled data with windowing (size = 10 samples)
To assess the presence of current flow, this section primarily focuses on calculating variations within a data set of 10 samples in the designated window area The variations are computed as follows:
The variations are analyzed across three distinct data set lengths: the first half, the second half, and the entire data set This approach facilitates logical comparisons, as illustrated in the previous flowchart (Figure 36), to effectively convert analog data into digital state messages.
Figure 36: Sequential diagram of communication between actors (User, Room Controller GUI), and Main Switch Node to the back end server
The Node operates two simultaneous tasks: one for detecting current sensor activity and the other for receiving commands from the RC back-end server The first task monitors the current flow triggered by either a physical button or a GUI touch button, detecting only the ON/OFF state and relaying changes to the Room Controller as formatted messages indicating “UAON” (User Action ON) or “UAOF” (User Action OFF) The second task continuously reads the communication channel for command messages from the RC back-end, which toggle the state of the managed light bulbs based on a digital signal of 1 or 0 Actions initiated by the node or main switch button subsequently operate the relay.
Dimmer Node
The Dimmer Node plays a crucial role in controlling the light bulbs within the room by responding to messages from the remote control (RC) that specify various brightness levels It effectively manages the lighting by utilizing a PWM board to adjust the brightness, ensuring optimal illumination in the space.
Figure 37: The particular architecture of the Dimmer Node
Similar to the previous Node, this one uses Arduino MEGA and ChibiOS with the multitasking architecture The dimmer board is used as the actuator
XBee Shield + XBee module ChibiOS
Figure 38: Inherited multitasking architecture for the Dimmer Node
In the architecture, the RX Task decodes the information and apply on the dimmer board with proper PWM signals
Figure 39: The operations of the RX task in the Dimmer Node
The RX Task flow chart outlines the process of handling packets from the Room Controller, decoding them, and executing the appropriate actions on the dimmer board actuator It extracts a three-digit number from the wireless packet payload, representing the desired brightness levels for the light bulbs The Node then utilizes a lookup table to determine the correct signal to transmit to its actuator.
Figure 40: Sequential diagram shows the communication between the Node and the Room Controller
The sequential diagram shows communication messages between the two systems in detailed formats.
Sensor Node
The Node is an important Node of the system where the information about the environment is measured, processed and sent wirelessly to the RC
Figure 41: The particular architecture of the Sensor Node
The Node, built on the Arduino platform and enhanced with ChibiOS software architecture and XBee components, features three sensors that monitor motion, light, and temperature These sensors collect data and transmit it to the Room Controller for efficient environmental management.
XBee Shield + XBee moduleChibiOS
Figure 42: Inherited multitasking architecture for the Sensor Node
In the multitasking architecture, there are three tasks that responsible for reading 3 sensors and send data to the TX Task The operations of three tasks will be discussed later
Figure 43: The operations of the Motion tracking task to send mail letter to the mailbox
A motion sensor is utilized to monitor movements within a designated area, using a timer to indicate whether the space is occupied or vacant The collected data is then transmitted to a mailbox, notifying the responsible party about the presence or absence of motion.
Figure 44: The operations of the Light level tracking task and Temperature tracking task to send mail letter to the mailbox
Figure 47 illustrates the data collection process from light and temperature sensors, highlighting their similarities Both sensors operate with a sampling period of 3 minutes, ensuring high-resolution environmental data for the central controller Once the data is collected, the task converts the readings into byte series for transmission.
Figure 45: Sequential diagram shows the communication from the Sensor Node to the Room Controller in formatted messages
The sequential diagram illustrates the formatted messages from three tasks, highlighting a unidirectional data exchange from the Node to the RC.
Door Lock Node
The Node manages the door lock by utilizing an RFID scanner to read user-specific RFID tags, which serve as keys Each user's unique key code is mapped and stored in a local MySQL database managed by the RC When access is requested, the Node scans the RFID key and sends it to the RC for verification; if the key is valid, the RC signals the door to unlock Additionally, the Node monitors the door's open and close status, with a simulated door lock actuator represented by an LED.
Figure 46: The particular architecture of the Door Lock Node
The Node integrates a magnet contact sensor and an LED actuator to provide its services, with the sensor detecting door status and the LED simulating a door opener Additionally, RFID technology functions as a key reader for the Node, enabling further processing of access control.
Figure 47: Inherited multitasking architecture for the Door Lock Node
In the architecture, we can see there are two tasks to manage the RFID scanner and the magnet contact switch The actuator is handled by the RX Task
LED to simulate the door lock actuator
XBee Shield + XBee module ChibiOS
RFID Radar Magnet contact sensor
Figure 48: The operations of the Door state tracking task on the left, and the RFID scanner task on the right
The left flow chart illustrates the process of reading the state of a magnet reed switch and outputting the data as mail letters This is achieved by continuously monitoring the peripheral and generating relevant data whenever there is a change in status.
The flow chart on the right illustrates the process of reading a key from the task and encapsulating it into 5 bytes of key data This data is then sent to the Mailbox before being transmitted to the TX Task, ultimately reaching the Room Controller.
Figure 49: The sequential diagram shows the exchange of formatted messages between the Room Controller and the Node
The diagram illustrates the process of transmitting formatted wireless payloads to the Room Controller There are two primary message types sent from the Node to the Room Controller: the asynchronous event indicating the door state (either opened or closed) and the key data obtained from the user's RFID tag.
Controller will verify the received key and emit packet to the Node to open the door if the key is right.
Window Node
The Node enhances room security by monitoring the status of two windows under surveillance It continuously checks the glass condition of these windows, ensuring any breakage from intruders or storms is promptly detected and reported.
Figure 50: The particular architecture of the Window Node
The subsystem employs two magnetic contact switch sensors to monitor the status of the window frames, along with a microphone sensor designed to detect the sound of breaking glass.
Figure 51: Inherited multitasking architecture for the Window Node
XBee Shield + XBee module ChibiOS
Magnet contact sensor Magnet contact sensor
As can be seen, the architecture has three tasks: two taking care of the magnet switch reading and the remained one is to checking the microphone sensor
Figure 52: 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)
The initial task in the Node involves glass breaking detection, crucial for enhancing room security This process continuously monitors analog values from the microphone sensor, comparing them against a threshold to identify the high-volume sound of breaking glass Additionally, two subsequent tasks track the states of two controlled windows, capturing their individual state changes and sending this information to the Room Controller.
Figure 53: The sequential diagram shows the exchanging formatted messages between the Node and the Room Controller
The diagram shows direction and types of formatted messages from the Node towards the Room Controller.
Summary
The chapter explores the prototyping process of Room Nodes, starting with a general overview that situates the Nodes within the broader system It then presents a unified architecture for both the software and hardware components of these Nodes.
The developer created a multitasking, two-way high-reliability communication software architecture for the Nodes This chapter detailed the implementation of the 5 Room Nodes and concluded with a summary The following chapter will focus on the design of the Room Controller and Building Server subsystems.