Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer and Information Science
Master thesis, 30 ECTS | Datateknik
202019 | LIU-IDA/LITH-EX-A--2019/103--SE
Low Latency Fog Computing
Architecture for a Fire Safety
Application
Simon Mehari
Supervisor : Mikael Asplund, Associate Professor Examiner : Mikael Asplund, Associate Professor
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Abstract
This thesis presents an architectural design for location-aware fire safety application (Fire-fly) based on cloud and fog computing. The Fire-fly application is designed to assist the residents of a building to be notified and evacuate individually in a fire emergency that is happening in the building by the help of sensor readings collected from within the building. A part of this thesis explains how this application is implemented using different types of communication models and protocols between different clients of the Fire-fly application. The communication latency is then measured and compared between cloud and fog architectures.
When it comes to communication between different clients, the fog architecture might be a preferred choice because it has lower latency than the cloud based architecture. How-ever this preference is questioned when it comes to dependability aspect. Therefore, this thesis also studies the dependability trade-off the fog architecture has by studying the availability of the fog architecture in a simulated failure of part of the fog architecture. The system restoration period of the fog architecture is measured by suddenly shutting down parts of the fog structure that are most likely expected to be exposed to physical damages because of fire.
The following results are achieved after testing the whole system on a test site: the average time it takes for data that contains location information from the resident client to arrive at the fire brigade client for the cloud infrastructure was 277 ms and for the fog was 14 ms. The results achieved from the service restoration period will approximately take on average 530 ms for a resident client to reconnect to a another functioning fog-cell in case of disconnection due to fire, and it takes on average 940 ms to reconnect to the cloud.
Acknowledgments
I would like to say thank you to:
• everyone who has been involved directly or indirectly with this project,
• AiMAZER - Xin Zhang, Wei Der Chien and Maxime Bonneau for the journey and for standing by my side in every challenge — you are wonderful,
• Mikael Asplund, my examiner, for all the support and for having an open door for educational discussions whenever I needed it,
• Kerstin Söderquist for all the support and spending hours on the test site as test pilot despite your exam coming the next day,
• Senion AB - for standing beside AiMAZER, and for providing the bluetooth beacons and the SDK for the calibration process on the test site,
• Mjärdevi Science Park for all your support from the beginning and letting me use Cre-active as test site,
• the UPP group (group for educating programming and program development) at IDA, Linköping Universtity, for being a part of you and all the technical advises and support I received from you,
• family members and friends. Thank you very much!
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables viii
1 Introduction 1 1.1 Background . . . 1 1.2 Motivation . . . 3 1.3 Problem Definition . . . 3 1.4 Research Questions . . . 5 1.5 Methodology . . . 5 1.5.1 Architectural Design . . . 5 1.5.2 Latency . . . 6 1.5.3 Dependability . . . 6 1.6 Delimitation . . . 6 1.7 Intended Audience . . . 6 2 Theory 8 2.1 Fire-fly Application . . . 9 2.1.1 Clients . . . 9 2.1.2 Server . . . 10 2.1.3 Communication Models . . . 11 2.2 Cloud Computing . . . 11 2.3 Fog Computing . . . 11 2.4 Latency . . . 12
2.4.1 End-to-End Delay Estimation with Timestamps in RTT . . . 13
2.4.2 Ping . . . 14
2.5 Dependability . . . 14
2.5.1 Attributes of Dependability . . . 14
2.5.2 Faults and Failure Severities . . . 15
2.6 Software Implementation Techniques . . . 15
2.6.1 Microservices . . . 15
2.6.2 Docker Containers in Application Virtualization . . . 15
3 Related Works 17 3.1 Concepts, Architecture and Other Related Applications . . . 17
3.2 Resource Provisioning and Latency . . . 18
4 Architectural Design and Construction of Fire-fly Application 20
4.1 Special Requirements . . . 20
4.1.1 Privacy . . . 20
4.1.2 Dependability . . . 20
4.2 High-Level Architectural Design Approach . . . 21
4.3 Operational and Design Solutions to Given Requirements . . . 22
4.3.1 Sequence of Operations . . . 22
4.3.2 Maintaining Fault-Tolerance . . . 24
4.3.3 Operational Modes . . . 24
4.3.4 Keeping Track of Clients . . . 24
4.4 Clients of Fire-fly Application . . . 25
4.4.1 Resident Client . . . 25
4.4.2 Data Collector Client . . . 26
4.4.3 Fire Brigade Client . . . 27
4.5 Cloud Architecture . . . 27
4.5.1 Application Container as Microservice . . . 27
4.5.2 Application Container Execution . . . 28
4.6 Fog Architecture . . . 28
4.6.1 Fog Cell . . . 29
4.6.2 Fog Controller Node . . . 31
4.6.3 Application Interface and Sequences . . . 32
4.7 Testing Environment and Scenario . . . 32
4.7.1 Installation and Configurations . . . 33
4.7.2 Testing Procedure . . . 33
5 Latency Measurements and Results 36 5.1 Latency Measurement Method . . . 36
5.2 Result . . . 38
6 Dependability Analysis, Measurements and Results 40 6.1 Testing Environment and Scenario . . . 42
6.2 Result . . . 43
7 Discussion and Future Works 44 7.1 Result Evaluation in Hypothetical Real-Time Scenario . . . 44
7.2 Evaluation Results and Overall Methods . . . 47
7.3 Future Works . . . 47
8 Conclusion 49
Bibliography 50
Appendices 53
List of Figures
1.1 Winners of ESH17 and Ultrahack 2017. . . 2
1.2 Latency comparisons for Fire-fly with cloud and fog architectures. . . 4
2.1 Alpha version of the resident client of the Fire-fly application. . . 9
2.2 Three types of clients and modules of operation. . . 10
2.3 Fog computing. . . 12
2.4 Virtualization using Docker containers. . . 16
4.1 System overview as client server architecture. . . 21
4.2 The three Docker images used by the containers and contained modules. . . 22
4.3 Sequence diagram: Emergency mode sequence. . . 23
4.4 Indoor positioning with bluetooth beacons in the test site. . . 25
4.5 Fingerprinted indoor map of the possible routes of the test site. . . 26
4.6 Cloud architecture and application container modules. . . 28
4.7 Sequence: Resident client connects to cloud and acquires the indoor map. . . 29
4.8 Fog controller node and two fog cells including their containers and modules. . . . 30
4.9 Bluetooth beacons. . . 33
4.10 Achieved fog architecture on test site. . . 34
4.11 Application test at the test site. . . 35
5.1 Sequence diagram: Emergency mode sequence. . . 37
5.2 Latency estimation timestamps for RTT. . . 37
5.3 Message latency measurement with timestamps. . . 39
5.4 Latency difference between mobile phone 1 (Samsung S8) and mobile phone 2 (Samsung Galaxy Young 2). . . 39
6.1 Service restoration sequences for cloud and fog. . . 41
6.2 Resident client reconnects to other fog cells when shutting down fog cell 2. . . 42
6.3 Service restoration period to reconnect to cloud vs. to another fog cell. . . 43
7.1 Cloud architecture sends one message/270 ms and fog architecture sends one message/14 ms. . . 45
7.2 Cloud and fog architecture scheduled message tasks scenario. . . 46
List of Tables
1
Introduction
This master’s thesis is selected by the student (author) in collaboration with AiMAZER — a start-up company under incubation by LEAD in Mjärdevi Science Park, Linköping. The purpose of this report is to describe the works and results of the thesis.
1.1
Background
In Sweden, there are about 100 fatal fires on average per year [26] [28]. Carelessness when smoking and arson are the most common causes of fires in public buildings [26]. In these buildings, there are potentially many people at risk, and it is not always the fire outbreak is a result of technical malfunctions or human mistakes alone, but it is also a result of deliberate fire setting by individuals for many and different motives and reasons. Because of this, one can assume that it will still remain a certain amount of fatal fires even though being aware of and protecting the building from the technical malfunctions or human mistakes. Neverthe-less, deliberate and intentional fire setting can always find a way to make the fire damages to happen.
The Swedish fire safety rules and regulations given by MSB —- Swedish Civil Contin-gencies Agency [27], require that every public building is equipped with clearly visible exit signposts and indoor maps of the building displaying evacuation routes that should be vis-ible at every entrance. Therefore, in Sweden, one can observe an emergency map visvis-ible somewhere around the main entrance of any public building. Moreover, the authorities have two strategies [26] to fight fire in public buildings: increasing the number of smoke detectors and give education of fire safety awareness to people. However, fatality due to fire accidents remains as a two-digit number [15] in many recent fire accidents.
The start-up company AiMAZER was founded aiming to solve the above-described prob-lem by impprob-lementing a location-aware application that can assist the resident of a building in the evacuation process during a fire emergency. Before the company’s emergence, this idea won the Best Project Award for East Sweden Hack 2017. Then, this idea further developed as a prototype, participated in Ultrahack 2017, in Finland, where it won the first price in the Open category - as seen in Figure 1.1. This master thesis builds on the work of the prototype of the Fire-fly application.
The Fire-fly application consists of a resident client and a fire brigade client. The resident client is a mobile application which visualizes an indoor map of the building and guides the
1.1. Background
user to a destination in the building. Moreover, the resident client, is used to notify the user when a fire emergency is happening in the building and assists them to the nearest and safest exit in the building. The fire brigade client is an Android tablet which is notified when a fire-emergency is initialized in the building, and it also receives collected information of the location information of the residents in the building.
(a) East Sweden Hack-17
(b) Ultrahack 2017
Figure 1.1: Winners of ESH17 and Ultrahack 2017.
One architectural aspect that is being widely used as a solution to manage applications with several types of clients, such as the Fire-fly application, is cloud computing. Cloud ser-vices described simply, are serser-vices that are used to give users the computing ability over the internet whenever a user demands it [24]. The fundamental limitation of cloud comput-ing, however, is the connectivity between the cloud and end devices for latency-sensitive applications [9], such as the Fire-fly application which is included in this latency-sensitive category. Fog computing, on the other hand, is a complementary architecture to cloud com-puting which aims to make communication faster and has lower latency than cloud comput-ing [25]. This thesis aims to study the two architectures and their differences in latency and dependability aspects in combination with the Fire-fly application in the process of saving lives in fire emergencies in public buildings.
1.2. Motivation
1.2
Motivation
The motivations for this study are to save lives in a fire situation in a building, and the mea-surement of the communication latency based on the two architectural platforms - namely cloud and fog computing, in the operation of saving lives by the Fire-fly application. A third motivation is to study how the dependability of the fog computing is affected by simulated fire-situation in a building. These motivations are further explained below.
In a fire emergency in a building, if the fire spreads to corridors, stairwells or other open spaces, the situation can quickly worsen [15]. The rate at which fire develops after ignition in the building is high, and people often fail to realize how quickly they must respond to a fire outbreak. Another problem that might be worth mentioning is the predefined division of responsibility - making sure that the residents evacuate the building. Visitors and residents rely on those who are responsible for taking necessary measures in the building during the fire situation. However, personnel in a building often lack proper training in how to deal with a fire. This is part of the problem the desired fire safety solution has to deal with: assisting every individual in the building in the evacuation process to safety by providing personalized evacuation routes and assisting the responsible people in keeping track of the people in the building during the stressful situation.
In the Fire-fly application, the collected data from sensing tiers must be immediately pro-cessed to trigger the alarm with an extremely low delay, or within a tolerable time constraint, if any. Moreover, the emergency should be visualized to the fire brigade with as low latency as possible. Thus the importance of using different types of architectures for the Fire-fly ap-plication to reduce latency as much as possible is highly desired and therefore measuring how much latency difference they have is considered as a motivation in this thesis. And fi-nally, in the future voice and video messages may be transferred between the clients, thus the need for a low latency communication architecture is highly desired.
However, the fog architecture, which is known to have lower latency [25] than cloud com-puting, is potentially exposed to physical damage due to situations that involve fire. This potential exposure affects the dependability of the Fire-fly application based on fog architec-ture. Therefore, measuring the availability of the system in a fire emergency scenario, where part of the system is damaged, is highly desired to be able to tell how the dependability of the Fire-fly application is affected.
1.3
Problem Definition
The Fire-fly application, as mentioned above, is a location-aware application that requires an architecture with low latency communication with the capacity of carrying data flow be-tween a growing number of IoT devices. To fulfill the relevant requirements for the chosen architectures as a communication media, the cloud-based architecture is as shown i Figure 1.2a, and the fog-based architecture as in Figure 1.2b.
1.3. Problem Definition
(a) Communication of resident client with fire brigade client based on cloud architecture.
(b) Communication of resident client with fire brigade client based on fog architecture. Figure 1.2: Latency comparisons for Fire-fly with cloud and fog architectures. Although fog computing is known to have lower latency [25] than cloud computing, the significant problem is to construct the two architectures in order to make a choice of architec-ture based on communication latency. To choose between the architecarchitec-tures, the measurement of the latency difference between the two architectures is required.
As mentioned above, the fog computing architecture has lower latency than cloud com-puting, and thus one might think to choose the fog computing over the cloud computing for this reason. However, fog architecture has some drawbacks because of the fire situations that could damage the devices. Therefore, another problem is to measure the availability of the system, in order to be able to tell how the dependability of the system is affected.
1.4. Research Questions
1.4
Research Questions
The following are the proposed research investigations based on the motivation and aim presented above:
• Investigate and develop an architectural design that coordinates the clients of the Fire-fly application based on cloud and fog computing.
• Investigate and measure the latency difference that can be observed between cloud vs fog computing applied to the Fire-fly application.
• Investigate how the dependability of the system is affected as a result of sudden mal-functioning devices in the fog computing architecture.
1.5
Methodology
The following are the methods that were used to answer the research questions:
1.5.1
Architectural Design
To be able to answer the first research question, architectural design for the whole system had to be developed for the Fire-fly application. The purpose of this application is to localize and guide a user to find the safest way out of a building during a fire emergency in the building. Here, the three clients of the Fire-fly application have different roles, responsibilities and requirements. Even though some parts of the clients existed from an earlier prototype, they had to be re-done for this new version. The following methods was applied to build and test the Fire-fly application with the new design:
• The Resident Client: an indoor positioning system, with bluetooth beacons planted in a test site, will be used to localize a user’s Android phone. From the fingerprinted positions of the site, a representation of the indoor map as a graph will be developed and used to build the virtual routes that represent the paths in the building. This graph will have information about exits and fire positions represented by blocked nodes on the graph. A simple pathfinding algorithm (Dijkstra or A-star) will be applied on the graph to find a path from a start point to a destination - which is a route to a known exit. Moreover, the notification and exit path will be visualized to the user on the phone. • The Data Collector Client: a Raspberry Pi is going to be used as a data collector client from
different simulated sensors and send the data to the server to be further processed. • The Fire Brigade Client: an Android tablet is going to be used to receive notification of
fire-alarms and collected position information of all the users in the building.
Cloud services from Amazon Web Services (AWS) - EC2 instance, is going be used as a cloud back-end server for the application. Further, three Raspberry Pis are going to be used as fog infrastructure to be installed in the site. A part of the design of fog architecture adapted from Skarlet et al. [34] is going to be applied for the implementation of the fog architecture.
After the implementation and integration of the cloud and fog architectures with the Fire-fly application, according to the gathered requirements, the first test is to see if the application works as intended and to verify that the two architectures present the same result. In order to do this, a test scenario is going to be executed in Creactive, Mjärdevi in Linköping, a public building where bluetooth beacons are to be installed and calibrated with the mobile appli-cation. The expected overall result for the test scenario is that a user located in the test site, using a mobile phone, is guided by the Fire-fly application out of the building in a simulated fire situation in the building.
1.6. Delimitation
1.5.2
Latency
For the second research question, the difference in communication latency between cloud ar-chitecture and fog arar-chitecture is going to be measured. The communication latency that will be measured is the position information the resident client sends to the server and further to the fire brigade client. Because fog computing is a supplementary architecture to cloud architecture, the latency comparison is going to be the latency of cloud architecture with and without a fog-supplementary component. The latency measurement is going to be performed on the same test site, in Creactive, as the test scenario mentioned above. Although there are many methods to measure latency, the selected measurement method is going to be a round trip time (RTT) measurement using timestamps. The accuracy level of RTT measurement is considered good enough to show the expected significant difference between the two struc-tures. For this method, a special button that enables the sending of messages with different package sizes is going to be implemented on the mobile application. The expected results of this test scenario are the timestamps on a log file acquired by pressing this button by a test pilot walking around in the site. After the calculation of the time stamps with the formula, the latency measurements of both the cloud and fog architectures is going to be compared.
1.5.3
Dependability
The availability of the system can be analyzed, in another scenario in the test site, by pur-posely halting or malfunctioning part of the fog architecture (fog cells) during a fire emer-gency simulation and allowing the clients to reconnect themselves to the system. For the third research question, this method will allow the measurements of service outage and ser-vice restoration periods, which will help to analyze the availability of the system and thereof to tell how the dependability is affected from the availability perspective.
1.6
Delimitation
The requirement elicitation process for the implementation of the system has produced a large number of requirements that do not fit in this report due to the size of its contents. Therefore, only the special requirements that are significant for the explanation of the design of the application are explained in this report.
The geographical location of the installed bluetooth beacons in the test site, due to confi-dentiality issues, are not reported or drawn where they are physically located in the building - they are positioned close to where the picture shows. This is because the test site is a public place and the devices should not be exposed to third parties.
The test results of the received location information from the resident client to the fire brigade client can only be confirmed from a log file of the fire brigade client. The timestamps for latency measurement for different packets that are collected from the test scenario are all obtained from log files after the test scenario was completed.
Finally, it is important to notice here that the aim of having a test site in a building is to collect real, not simulated, position information of a resident client in the building. However, the pictures of the test pilot on the test site, in Chapter 4, do not represent the numerical results; they only illustrate how the testing of the application was performed.
1.7
Intended Audience
This thesis is intended to be understandable by anyone with the interest and ability to read technical documentation. No prior knowledge is required in cloud computing, fog comput-ing, latency or dependability. The Fire-fly application is a product that comprises different state-of-the-art technological methods in order to fulfill its purpose. The techniques this thesis
1.7. Intended Audience
uses are described to a relevant level so that anyone with a technical mindset can understand them.
2
Theory
"When wireless is perfectly applied the whole earth will be converted into a huge brain, which in fact it is, all things being particles of a real and rhythmic whole. We shall be able to communicate with one another instantly, irrespective of distance. Not only this, through television and telephony we shall see and hear one another as perfectly as though we were face to face, despite intervening distances of thousands of miles; and the instruments through which we shall be able to do this will be amazingly simple compared with our present telephone. A man will be able to carry one in his vest pocket."
Nikola Tesla, 1926 This chapter first discusses some historical background and the system overview of the Fire-fly application that has existed before the start of this thesis. Then, it explains the theo-retical context of the topics that the thesis is mainly based upon, namely: cloud computing, fog computing, latency and dependability. Even though there is a great deal of science and history behind these topics, this section discusses each of the topics to a considerably appro-priate level of detail to make the report understandable by the reader. Lastly, a high-level explanation is given to some theoretical background for the software implementation tech-niques, such as microservices and Docker containers in application virtualization, that are used in this thesis. For further information about the topics, it is advisable to follow the references that are included in the contents of the topics.
2.1. Fire-fly Application
2.1
Fire-fly Application
The Fire-fly application, developed by AiMAZER, is an application that falls in the category of smart home and smart city solutions and is designed to notify and assist residents of a building with evacuating the building during fire emergencies. The type of clients it com-prises and the modules that the server contains are explained below.
2.1.1
Clients
The available application was a prototype of a resident client as shown in Figure 2.1. The figure shows the user interface of the resident client which is a portable client that runs on an Android phone. It also shows an indoor map of the hall for the Ultrahack 2017 hackathon event, where all the participants of the hackathon were placed to work on their projects. The indoor map includes the picture of pieces of furniture such as tables, chairs and a stage. The red polyline is a path to follow, drawn for the user in order to be able to escape the fire, shown as a fire icon, which has appeared right at the location of the resident client which is marked with a blue dot in the picture. The indoor map is responsive to the cardinal directions and rotates to the right direction depending on the direction the user is pointing the mobile phone towards. The resident client uses bluetooth beacons to localize itself on an indoor reference map on its user interface as explained above. The functions of this client are to notify the user in case of fire emergency, localize itself on a reference map, and lastly, use pathfinding algorithms to assist the user to find his/her way to the nearest and safest exit.
Figure 2.1: Alpha version of the resident client of the Fire-fly application.
The second type of client, the fire brigade client, is also a portable client, this time on an Android tablet. This client visualizes the current situation of the building: the map of the building, the current locations of all the resident clients in the building, the current location of the fire, the current temperatures of the rooms and corridors of the building and finally the locations of necessary items (fire extinguisher, blankets, ladder, sand etc.).
2.1. Fire-fly Application
The third type of client, the data collector client, is developed and executed on a Raspberry Pi. By using bluetooth communication, it collects sensor data from smart smoke detectors, temperature and pressure sensors in the building. It then further sends the collected data to a centralized server for further processing.
Figure 2.2: Three types of clients and modules of operation.
2.1.2
Server
The back-end of the application was deployed on a local server. Notice that this part of the system is replaced by cloud and fog architectures in this thesis. As shown in Figure 2.2 there are five modules that have different functionalities on the server. These are clients’ gate, fire detector, dispatcher, map controller and information distributor.
The clients’ gate module is the connection gate the clients use to connect to the server for accessing the different types of services. The fire detector is the module which is responsible for filtering and checking the presence of possible fire emergency by reading the incoming sensor data from the data collector client.
In case of detected fire emergency, the dispatcher module is responsible for sending emer-gency signals to the notification senders that use the Android Notification Service. The noti-fications are sent both to the resident clients that are considered to be involved in the emer-gency situation and the fire brigade clients.
The map controller module is responsible for updating the indoor map, represented as a graph with nodes and edges in a JSON-format, according to the fire detector module which in turn depends on the information collected by the data collector client. The information distributor module is responsible for distributing the map information to the selected resident clients that are involved in the emergency situation, depending on their location information.
2.2. Cloud Computing
2.1.3
Communication Models
The Fire-fly application uses Hyper Text Transfer Protocol (HTTP), WebSockets and Message Queue Telemetry Transport (MQTT) as communication protocols between the clients and the server. HTTP is a communication protocol that is based on request/reply between the client and server communication, where the client can send an HTTP-request with specific attributes, and the server gives responds respectively.
WebSocket is a computer communication protocol that provides communication channels over a single TCP connection [17]. It enables two-way communication between a client and the server, and it consists of an opening handshake followed by necessary message framing, layered over TCP. [17]
The MQTT communication protocol is a lightweight Machine-to-Machine (M2M) protocol that works on simplified TCP, and it belongs to the publish/subscribe category. Publish/sub-scribe messaging requires less communication bandwidth [37] and computational power in IoT applications compared to request/response messaging protocol. According to Venanzi et al. [37], MQTT architecture can be broken down into three main components as follows:
• Subscriber is an entity that is subscribed to one or more topics, which automatically receives updates from the broker about its subscribed topics.
• Publisher is an entity that publishes messages on one or more topics while these mes-sages are delivered to the subscribers by the broker.
• Broker is a server that waits for the incoming messages on the topics and dispatches them upon receipt. Publisher/subscriber peers communicate through a topic without knowing each other. An example of a broker server is "broker.hivemq.com."
2.2
Cloud Computing
The definition of cloud computing, according to Mell and Grance [24], is: "a model for en-abling convenient and on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services)." In other words, it is a model that has a configurable computing resource that can conveniently be shared via net-work by end users. These resources can be easily provisioned with low management effort from the service provider.
The resources provisioned by cloud providers such as Microsoft, Amazon, IBM, Google, etc., include software-services accessed via web-browsers and developer platforms to create and deploy cloud applications. They also include entire server infrastructures that handle Virtual Machines (VMs) running on cloud resources.
2.3
Fog Computing
The growing number of IoT devices heavily rely on cloud computing due to some limitations of the cloud infrastructure. The end devices progressively demand faster communication and more resource capabilities from the cloud infrastructure. Thus, to address this limitation and shortcomings of the cloud computing, a fog computing platform was introduced by Cisco in 2012 [25].
Although the concept of fog computing has had several definitions as it is moving towards its maturity, the following definition can be used according to Thien et al. [36]:
"Fog computing is a distributed computing architecture where it contains connected het-erogeneous devices geographically placed closer to the edge of the network as an extension to cloud services, to provide elastic computation, communication, and storage to a large scale of clients."
2.4. Latency
In other words, fog computing is a computing architecture that has heterogeneous de-vices, that extend the cloud in a network. These dede-vices, which are always in continuous connection with the cloud, are geographically placed closer to the end-user in between the cloud and the edge of the network, providing elastic computation and storage to the end-user.
Figure 2.3: Fog computing adopted from [25] and [21].
What makes fog computing interesting is that it has characteristics that makes it possi-ble to solve certain types of propossi-blems easier than cloud computing. The following are the characteristics of fog computing according to Thien et al. [36] and [25]:
• Location awareness: In contrast to the centralized cloud computing, the services and applications can be supported by distributing the resources to geographical locations where it fits the system best.
• Edge location: Applications which are dependent upon locations can be supported with low latency in communication.
• Scalability: As a result of geographical distribution of the service, large amount of clients can be distributedly served.
• Mobility: It is essential for many fog applications to communicate directly with mobile devices, and therefore support mobility techniques such as the LISP protocol that de-couple host identity from location identity, and require a distributed directory system. • Heterogeneity: Fog nodes come in different form factors and will be deployed in a wide
variety of environments.
2.4
Latency
Latency in communication is the delay that takes place during communication over network. The four types of delays that affect the end-to-end delay in communication are processing delay, queue delay, serialization delay and propagation delay [21]. Thus, the overall
end-to-2.4. Latency
end delay, Dend´to´end, will be approximately the summation of the above four delays times the number of nodes the packet passes through.
Dend´to´end=N ˚(dproc+dqueue+dseri+dprop) (2.1) In Eq. (2.1) dprocis nodal processing delay, dqueueis queue delay, dseri is serialization de-lay, dpropis propagation delay and N is the number of network segments a packet must go through along the IoT ecosystem.
With the advancement of both hardware and software, the value of dproc and dseri per node are on degree of microseconds, while dqueuecan be optimized by prioritizing and selec-tion of some data [21]. In the Fire-fly applicaselec-tion’s case, the WebSocket communicaselec-tion is a non-blocking type and the connection is kept alive as long as the fire brigade client is in the building. Meaning, for every newly established connection, a new thread is executed that runs in parallel so that aside from the network queue the application aims to eliminate the queuing delay at gates of the cloud or fog stratum nodes.
There are several types of latency estimation approaches. Nowadays, the usual approach is through the assistance of Network Coordinate System (NCS) that establishes a virtual po-sitioning system for every node [21] - and most of the algorithms can achieve 90 percent accuracy of latency estimation. This algorithms are based on one-way delay (OWD) and/or round trip time (RTT) measurement. In this thesis the RTT is adopted because the OWD tech-nique requires a highly synchronized clocking and precise time stamping across all the nodes in the network path.
2.4.1
End-to-End Delay Estimation with Timestamps in RTT
According to Network Working Group (NWG) of the proposed standard RFC 2681 [2] and Nunzi et al. [30] the RTT between a source and a destination node is defined as
∆T=∆ T1´T2 (2.2)
where "T1is the time at which the first bit of the request packet sent by the source node approaches the physical layer, and T2is the time at which the last bit of the response sequence, immediately sent back by the destination node, leaves the physical layer" [30].
A generic procedure that should be followed, according to RFC 2681 [2] and [30] for the parameter in RTT and the above given Eq. (2.2) are:
1. The source should have a test packet with given length containing the IP addresses of both the source and the destination.
2. The destination should be able to receive the test packets and answer as soon as possi-ble. The source host should be able to receive the response test packet.
3. The source host should be able to save the time reference value just before sending the test packet.
4. The final time stamp (T2) is considered upon the receipt of the packet, if the response packet arrives at source within a predetermined time interval.
5. RTT is calculated by subtracting T2 from T1.
When considering the RTT measurement method, i.e., sending test packets across the net-work and time stamping the test packets in each node the packets pass by, there is an im-portant aspect to consider when it comes to time stamping: making sure that the CPU clock runs at constant rate across all sockets in a node. The Linux kernel 2.6.18 is the first version that includes the hrtimers [14] package and this includes support for most of the different clock sources [18]. This is done by using a CPU with a constant and an invariant time stamp
2.5. Dependability
counter (TSC) and configuring it as the clock source for the Linux kernel at boot time. This means that the TSC runs at a constant rate across all sockets/cores, regardless of frequency changes made to the CPU by power management code.
In case of an Android environment, where the resident client and the fire brigade client run on, the library class Timestamp [4] can be used. This class adds the ability to hold the SQL TIMESTAMP fractional seconds value, by allowing the specification of fractional seconds to a precision of nanoseconds.
2.4.2
Ping
A way to measure/approximate network latency is the ping command. According to the Linux Manual Page, an application or a user can communicate with an underlying operating system with this standard command, ping, which is used to either detect whether the network is operational or/and detect if the network has an actual connection to a far end destination across the network. This command uses the Internet Control Message Protocol (ICMP) [33].
Similarly, the echo command can be used to send a token message across the network. As a result, one can be able to determine if the network is connected and at least usable if the token message makes it to the far end destination and an echo message returns to the sender. Another useful command is the traceroute command that can be used to roughly approximate a route that a sent token message may take to traverse the network.
In summary, by using the ping command one can identify that both ends of the network are connected and operational. Additionally, by utilizing a ping command, one could ap-proximate the total time elapsed from a time when the ping command was issued to a time when the ping command has returned with a value. This would approximate the total round trip time (RTT).
The ping command, however, measures only host-to-host message communication but not application-to-application message communication, i.e., the command issues a token message from the lower layers of the operating system. This means that the token mes-sage indeed does not travel end-to-end across the network including the latency up to and including the application layer of a computer system at each end of the network.
Therefore, the ping network command may be used to approximate the network latency but it may not be used to accurately measure the connection latency that is significant for the application layer. For this reason another method, RTT with timestamps, is chosen to measure latency on the Fire-fly application.
2.5
Dependability
The third research question refers to the dependability of the Fire-fly application and how it is affected by the choice of architecture. To be able to answer this question, it is therefore essential to have a concrete definition and know the attributes of dependability.
Dependability is defined according to [6] as: "the ability to avoid service failures that are more frequent and more severe than an acceptable level".
2.5.1
Attributes of Dependability
The concept of dependability includes some attributes listed below according to Avizienis et al. [6]. Moreover, some formal definitions of essential terms are going to be explained below.
Attributes of dependability:
• availability: "readiness for correct service", • reliability: "continuity of correct service",
2.6. Software Implementation Techniques
• integrity: "absence of improper system alterations",
• maintainability: "ability to undergo modifications and repairs".
When a system transitions from a correct service to incorrect service it is, in this thesis, said to have service failure. It is an event that occurs when the delivered service deviates from the correct service, where the deviation from the correct service is called an error. This service failure causes service outage, which is the period in which a system delivers an incorrect ser-vice. A service shutdown is an intentional halt of service by an authorized entity. The adjudged or hypothesized cause of an error is called a fault. [6]
According to the definitions above, failures, errors and faults are threats to dependability.
2.5.2
Faults and Failure Severities
Fault tolerance is a means of attaining dependability [6], and it means to avoid service failure in the occurrence of faults. This thesis focuses on this means although other suggestions on how to attain dependability for the Fire-fly application are going to be mentioned later in Chapter 6.
The types of faults that belong to three major categories are: 1) development faults: the fault classes occurring during development, 2) physical faults: fault classes affecting hardware, and 3) interaction faults: the external faults. The type of fault this thesis mainly focuses on are physical faults.
Failure securities can be defined by grading the consequences of the failures upon the system environment. By involving the dependability attributes that were described above, labeling and setting the severity levels for an application can be done to see how the depend-ability of an application or system is affected. One of the attributes that can be looked upon is availability. To define the severity level for availability, the outage duration can be measured and labeled at different levels. This thesis focuses on measuring the service outage to tell how the dependability of the application is affected by this perspective.
2.6
Software Implementation Techniques
Below are the two software theories and techniques that are very useful in modern software development and has been of great use in this thesis: Microservices and Docker Containers in application virtualization.
2.6.1
Microservices
Microservices [20] are: "small applications with a single responsibility that can be deployed, scaled, and tested independently." Inspired by service-oriented computing, applications built with microservice-based architectures are structured in a way to make effective development and test processes, and improve the application’s modularity. Moreover, they enable continu-ous delivery, and the services are independently deployable. This approach is used mainly in the development of the fog architecture in this thesis, and this is explained further in Section 4.6.
2.6.2
Docker Containers in Application Virtualization
A container is according to [11]: "a software environment where one can install application components (such as microservices) and the necessary configurations and dependencies of the component that is necessary to run the application." Containers provide the ability not only to start/stop the containerized microservice, but it also provides the ability to upgrade and release a new version of the application. Moreover, the use of containers provides a
2.6. Software Implementation Techniques
higher level of abstraction for the process lifecycle management. Containers and applica-tion virtualizaapplica-tion became famous in 2013 with the launch of the Docker open source project (docker.com). Containers become more interesting and even more popular because they potentially may solve the dependency hell problem - a term used for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.
Probably the main reason that containers are advantageous is that a microservice can be executed on any platform supporting containers. Moreover, they introduce lower overhead compared to Virtual Machines [11].
Figure 2.4: Virtualization using Docker containers, picture adopted from [19]. When using Docker, a Dockerfile defines what goes on in the environment inside a con-tainer. It is generally recommended to use one service per concon-tainer. That service may fork into multiple processes (for example, an Apache web server main process starts multiple worker processes). It is allowed to have multiple processes, but to get the most benefit out of Docker, according to the Docker documentation [19], it is advisable to avoid one container being responsible for multiple aspects of the overall application. Connecting multiple con-tainers can be done by using user-defined networks and shared volumes. Volumes can be shared with other containers in the same machine, and they are also useful for backups, re-stores and migrations. More information about Docker containers and Volumes can be found in www.docker.com.
3
Related Works
This section discusses some related works and similar projects. Three perspectives were con-sidered when selecting the related works. The first perspective is the design and architecture of some available indoor applications that use the cloud/fog hybrid combination. A second perspective is latency estimation methods and some resource provisioning methods in the fog architecture to achieve even lower latency. The third perspective is the dependability in the fog architecture.
3.1
Concepts, Architecture and Other Related Applications
Bibani et al. [9] demonstrates a use case of robotic prescription distribution and medication delivery. This use case uses Platform-as-a-Service (PaaS) that enables provisioning of data for IoT applications in hybrid cloud/fog environments. This project is an application that consists of three subsystems: Medical Data Collection Subsystem, Automatic Medication Pre-scription Subsystem, and Robotic Medication Delivery Subsystem. What makes this project relate to the thesis is that its structure of the system and the concept of subsystems function-ality resemble the data collector client, fog/cloud, and the fire brigade client in the Fire-fly application. It has inspired this thesis in making a modular design of the Fire-fly application. Another related work from Negash et al. [29] on a smart e-health gateway implementation (connecting a network of gateways in the fog layer) both in the home and hospital use. By pre-senting a simple scenario and features of gateways, the fog implementation is discussed and evaluated from different perspectives, e.g., data management, event management, resource efficiency, device management, personalization, and privacy and security. The gateway sub-module of the Fire-fly application’s non-blocking implementation has been done by taking into consideration the future work to be done and having [29] in mind.
Arguing that cloud computing and smart items can be powerful enablers of services as a business trend, Stanchiev et al. [35] present a three-layer architecture for a smart healthcare infrastructure that is enabled by fog computing. This argument seems realizable, meaning, that the Fire-fly application can be designed in a similar way and can be integrated with other healthcare sectors applications in order to play a vital role in improving the quality of health services.
Another work that has been a base for the design of the fog architecture is that of Skar-let et al. [34]. This paper presents a conceptual framework and architectural design for fog
3.2. Resource Provisioning and Latency
computing that is optimized for resource provisioning. It then presents an optimization prob-lem that provides "delay-sensitive utilization of available fog-based computational resources" [34]. The fog computing architecture comprises a fog orchestration control node that acts as a middleware between the cloud and fog cells that make up the fog colony. The main signifi-cant feature this thesis did not adopt from the design is the database that the fog cells possess. The fog cells of the Fire-fly application are not allowed to physically store the data. More of this and the design of the fog cells and fog controller nodes can be found in Section 4.6.
Another related project is Bachman’s [7] fog computing master’s thesis that also follows the works of Skarlet et al. [34]. A similarity is the implementation of the fog cells and con-troller nodes. Both this thesis and [7] use Docker as application virtualization method. How-ever, Sun Microsystems library and Java SDK are used for the implementations of fog cells and fog controller nodes in Bachman’s thesis. Unfortunately, the used Java library and devel-opment language were assumed to be too slow, and the general object-oriented architecture was considered to be too complicated, for the Fire-fly application by AiMAZER. As a result, the choice of libraries and the development language of the fog cells and fog controller nodes for the Fire-fly application was designed differently. Another difference between Bachman’s implementation and this thesis is the difference in the usage of volumes in order to share data between Docker containers. The choice of the development language, Python, in the Fire-fly application, makes it more flexible in selecting how parallel running processes in different containers communicate with each other. The Fire-fly application takes advantage of this fea-ture to solve the complication of the design and architecfea-ture that is used in Bachman’s design. What more of this and other details of the design choices for the fog computing specifically made for the Fire-fly application can be found in Chapter 4.
3.2
Resource Provisioning and Latency
Li et al. [21] is one of the related works that has been the main focus before and during the implementation of the fog architecture for the Fire-fly application. This paper studies the components of network delays and develops a latency estimation framework for fog-based IoT. Besides giving different latency estimation approaches and methods to estimate how good the latency estimation is, it proposes a highly accurate latency estimation method and algorithm called Fog-Based IoT Latency Estimation (FILE). However, in this thesis FILE is not used, because, as mentioned before in Section 1.6, the accuracy level and the method used for this thesis (calculating RTT by using timestamps) is considered to be good enough to show the significant latency difference between cloud and fog architectures in the Fire-fly application.
Ashrafi et al. [5] proposed an infrastructure with a collaboration of fog computing com-bined with M2M intelligent communication protocol. This work proposes an architecture that is able to transfer data reliably with low latency, less bandwidth, heterogeneity in less amount of time maintaining the Quality of Service (QoS). This infrastructure resembles the Fire-fly application’s modular infrastructure. From this related work one could understand that M2M communication is possible to be applied and be used in the future.
By addressing some challenges of resource distribution, Giang et al. [13] propose a Dis-tributed Dataflow (DDF) programming model for the IoT that utilises computing infrastruc-tures across the fog and the cloud. This data flow model is used in the distribution of the data collected by the data collector client in the Fire-fly application. Giang et al., evaluate the proposal by implementing a DDF framework based on Node-RED (Distributed Node-RED or D-NR). This approach inspired some part of the test approach which the Fire-fly application used in order to collect and send data from simulated sensors to different fog cells.
By providing an efficient architecture and algorithm for resource provisioning in fog com-puting, as the title of the paper states, Agarwal et al. [1] has inspired the architectural model of the Fire-fly application. Even though no direct credit is given to this work in this thesis,
3.3. Fog Computing Reliability and Dependability
it has been a positive inspiration source in how to think when designing an architecture that emphasizes resource provisioning.
3.3
Fog Computing Reliability and Dependability
An interesting project that reviews the fog architecture’s reliability and dependability is a paper written by Popentiu-Vladicescu and Albeanu under the title Software Reliability in the Fog Computing [32]. In this paper, some attributes of dependability, which are reliability and availability, are discussed from a fog architecture perspective. When we say the reliability of the system, it is meant that the system is expected to have a reliable operation on the hardware the software is running on, with reliable software, on a reliable fog network. Thus, three components of the system reliability are considered [32]: the nodes reliability, the network reliability, and software reliability. Moreover, availability of the system means [32]: "that the system is expected to assure, by secure access in all levels, orchestration, manageability, control and fault isolation."
This paper discusses and also gathers from other works some approaches or methods for fog reliability assurance. One of the methods mentioned, that can be used to increase the fog reliability in case of an occurring disaster was to reconnect, if possible directly, the surviving devices to the network right after the occurrence of the disaster. The mentioned disaster may include power outage and any dysfunction of a part the infrastructure due to physical damage. This detecting and reconnecting approach has inspired the design of a module in the Fire-fly application which is described in Section 4.6.2. More importantly, his paper discusses that the reliability can be assured by enhanced hardware, software, and network designs, including fault-tolerant approaches which the Fire-fly application also considered to apply in the system. [32]
As a solution to assure the dependability of the system, [32] also suggests that the fog net-work is empowered by Software Defined Netnet-working (SDN). This SDN allows the netnet-work to have a controller on the end nodes of the fog network that should be able to withstand mobility and unreliability in the network link. Another suggestion is that the fog network is empowered by Network Functions Virtualization (NFV) that improves the services by the “virtualization of gateways, switches, load balancers, firewalls, and intrusion detection de-vices” by integrating the virtual machines on fog nodes. [32]
4
Architectural Design and
Construction of Fire-fly
Application
This section explains the architectural design used for the construction of the Fire-fly appli-cation. It explains how the clients of the Fire-fly application work together based upon both cloud and fog architectures.
Software Developments Life Cycle (SDLC) [8] is the method used for implementation of the application. This means, first, the general requirement elicitation process for the whole system was done. Then after an iteration of analysis of the requirements, a design that is able to coordinate the clients and meet the requirements was developed. Then, implementation and testing according to the requirements and deployments operations were performed in several iterations until the whole system was finally fit to be tested on a test site. The result of the iterations and the methods used to coordinate the clients with both cloud and fog architectures is explained below.
4.1
Special Requirements
After carefully studying the desired result of a modular design of the system, AiMAZER has prioritized specific requirements that fit this master thesis. A large number of requirements has been gathered from the stakeholders. However, privacy of information, as required by EU General Data Protection Regulation (GDPR) [31], and the dependability of the system has been the two major factors in the design of the system, and these are explained below.
4.1.1
Privacy
Probably the most sensitive information the system will require to have access to is the po-sition information of the users who have chosen to install the application on their mobile phones. Two main examples of requirements in the privacy area are that the system shall not save any user’s position information on a disk or database at all, and that the user’s position information shall only be shared with the system if the user allows it.
4.1.2
Dependability
The other significant feature the system shall have as a requirement regarding dependability is that the system shall be fault-tolerant and the system outage time shall be measured in
4.2. High-Level Architectural Design Approach
order to tell how dependable the system is. Therefore, hardware redundancy shall be applied to different parts of the system. This shall include more data collector clients and several fog cells in the building in order to tolerate the destruction caused by the fire environment that the system is designed to operate on. How dependability of the system is affected by the fire damage on the system is part of the question the thesis aims to answer.
4.2
High-Level Architectural Design Approach
The architectural design of the whole system is of client server type. As a result of this design choice, as seen in Figure 4.1, the system has two distinct layers: the server layer and the client layer.
Figure 4.1: System overview as client server architecture.
The server layer contains the cloud layer and its extension, the fog layer. The overall de-sign of the server layer (both the cloud and fog layers) is modular. These modules, depending
4.3. Operational and Design Solutions to Given Requirements
on their purpose, are put into three different Docker images and containers as microservices and deployed on the cloud or/and fog layers. As shown in Figure 4.2, the three containers are Application Container, Controller Container, and Cell Connector Container. How these containers are deployed on cloud and fog architecture is illustrated in Figures 4.6 and 4.8. The application container is the container that is deployed on the cloud as a microservice to serve the Fire-fly application. The application container contains the five modules that all the clients connect to: The clients’ gate, fire detector, information distributor, map controller and dispatcher. How this application container works, and its result of the sequence of events is described in Section 4.5. The cell connector container is deployed on the fog cell along with the application container. The cloud layer runs on the Amazon Web Services that provides cloud services and the necessary resources. Details of the cloud layer is further explained in Section 4.5. The fog layer contains the fog cells which run on a Raspberry Pi, this is further explained in Section 4.6.
Figure 4.2: The three Docker images used by the containers and contained modules. The client layer contains the three types of clients: resident client, data collector client and fire brigade client. The resident client and the fire brigade client are Android applications deployed on a mobile phone and a tablet respectively, while the data collector client runs on a Raspberry Pi that collects data from different sensors used to monitor the environment. These clients play different roles, and they are explained below in Section 4.4.
4.3
Operational and Design Solutions to Given Requirements
Some of the requirements - like maintaining fault-tolerance, keeping track of the resident client ID without using a database and alerting the fire brigade client in specific alarming sit-uations - are all solved and explained as follows below. A sequence diagram, also explained below, shows the flow of information between the clients and the server of the Fire-fly appli-cation.
4.3.1
Sequence of Operations
The sequence diagram in Figure 4.3 shows the normal sequence of events and data flow between the three clients and the server which contains the application container. Notice that the server layer runs the two different architectures: the cloud and the fog architectures, and this is the expected result of the application container regardless of where this container is deployed - either directly on the cloud, or the fog cells.
The sensor data collected by the data collector client is sent to the server continuously. The data is then filtered through the fire detector module. How data is sent from the data
4.3. Operational and Design Solutions to Given Requirements
Figure 4.3: Sequence diagram: Emergency mode sequence.
collector client is explained in Section 4.4.2. How the server (which is either the cloud or the fog layer) controls the fire detection process is explained in Section 4.3.2. In Section 4.3.4 it is explained how the server keeps track of the clients. How the cloud and fog architectures maintain the same result is explained in Section 4.5 and 4.6 respectively.
Notice that all the clients connect to the application container on the server layer first. If the fire detector module that detects if the sensor reading has fire-emergency signals, the in-formation distributor module in the application container sends notification to the resident client and the dispatcher module sends the dispatch signals to the fire brigade client. The resident client who has accepted the emergency notification then sends its position informa-tion back to the server. How the posiinforma-tion informainforma-tion is acquired and is sent to the server is further explained in Section 4.4.1. Then, the server layer sends further this position informa-tion to the fire brigade client. Notice that the communicainforma-tion latency that this thesis aims to measure is the position information that the resident client sends to the server and further to the fire brigade client - these are the blue lines noted with the position info in the sequence diagram in Figure 4.3. The red lines are sensor data that are collected from several data
col-4.3. Operational and Design Solutions to Given Requirements
lector clients and this data is simulated in this thesis. The fire brigade client then receives and visualizes the positions of the position information of the resident client and this is explained in Section 4.4.3.
4.3.2
Maintaining Fault-Tolerance
Even though the sensor data is simulated, the way to evaluate the sensor readings in the safe mode has been made very simple, where the sensor readings are iterated through on the server and checked if they are over or below a certain level. In order to increase the dependency on the part of the system which is more vulnerable to fire, hardware redundancy is applied. This redundancy is applied where some data collector clients are placed and scattered in places where a fire is more likely to happen. As a result, this creates more data to evaluate but more importantly will result in data redundancy, i.e., the same sensor reading is reported from different data collector clients. This can be solved by having a voting system for the incoming data in the fire detector module on the server.
4.3.3
Operational Modes
There are two different types of operational modes of the system: safe mode and emergency mode. In the safe mode, the only client who is active is the data collector client which collects sensor data and reports. The primary trigger that makes the system switch from the safe mode to the emergency mode is the temperature and humidity sensor readings and a smart smoke detector trigger read by the data collector client. Looking closely, the three triggers that make the system change between the two operating modes are: 1) any temperature or humidity sensor reading above a certain level, 2) detected smoke signal by smoke detector, 3) the absence of any specific sensor in the data report by the data collector, or 4) a failure of the data collector client for any reason. In case of the above triggers, the fire brigade client is notified and becomes ready to receive location information from resident clients.
During the safe mode, the data collector client has to collect data from the sensors and continuously update the system every 30-60 seconds, with HTTP protocol, which is called scene-updating interval. The reason for the choice of 30-60 seconds interval, during the safe mode, is to minimize the traffic between the server and the numerous data clients that are found in the building. Besides that, as a backup, the MQTT publish-subscribe system will cover-up and update the system every 3 seconds with just enough information to trust the time gap that the HTTP has.
Although, during the emergency mode, the scene-updating interval is reduced to 1 second and the system focuses on the data flow that runs through WebSocket protocol that connects to the server as soon as the emergency is noticed.
4.3.4
Keeping Track of Clients
To keep track of the clients, during both operational modes, a client ID is generated by the clients’ gate in the application container and is assigned to a client. This happens the moment a client enters the building, i.e., sends a request for the indoor map. The indoor map is then sent to the client by the map controller module after it connects itself with the server with WebSocket pipe that is kept alive as long as the client is in the building. The client is assigned to another random generated client ID the next time it enters the same building.
In order to keep track of the clients and send the necessary information to them, a dic-tionary data structure that contains the client ID and the socket-object is used. Moreover, a hash map data structure is used to store the client ID and the building ID in order to figure out which client is in which building. Once the fire emergency is triggered by the fire detec-tor module the system should be able to notify the users in the building by the information distributor module.
4.4. Clients of Fire-fly Application
4.4
Clients of Fire-fly Application
This section describes the clients and how they function to fulfill their requirements. As men-tioned earlier, the three types of clients are resident client, data collector client and fire brigade client. The main purpose of the server is to notify the resident client and to orchestrate the collective information that comes from the resident client and the data collector client and making it available to the fire brigade client. How these clients perform the different tasks is further explained below.
4.4.1
Resident Client
The resident client is, as explained before, an Android application on a mobile phone, and it executes the following operations to fulfill its purpose: indoor positioning using bluetooth beacons, reading a fingerprinted virtual indoor map and calculating safest and nearest way to the exit. The calculated indoor position is sent further to the server layer, as seen in Figure 4.3.
The indoor positioning operation is powered by a company called Senion which means AiMAZER uses Senion’s software, that links a given indoor map to Senion’s bluetooth bea-cons which are identified and linked to the software. This software is then used to calibrate the bluetooth beacons to the application.
(a) Indoor map of the test site. (b) Indoor map of the test site and posi-tions of the bluetooth beacons (circles). Figure 4.4: Indoor positioning with bluetooth beacons in the test site.
• Indoor positioning using bluetooth beacons: By placing the bluetooth beacons in the building on a spot where they are geo-referenced in advance, the Android phone can localize itself by reading Received Signal Strength (RSS) of the beacons. In any build-ing, where the application is going to be deployed and tested, bluetooth beacons are installed in advance on the walls and the roof of the rooms. These bluetooth beacons are small size transceivers, and each one has a unique ID.
To illustrate this by an example, shown in Figure 4.4b, the bluetooth beacons (the circles) are placed on the walls of the building. The x-spots are marked on the map, and they represent the corners of the building. The bluetooth beacons geographical location can be geo-referenced by GPS signals from Google Maps in reference to the corners of the building. Geo-referencing basically means saying ‘point P on the image is at geographic coordinate Q’. More about how the test site is set-up is explained later in Section 4.7. • Virtual indoor map from fingerprinted positions: The virtual indoor map is
consti-tuted from several points, geographical positions that have specific signal strengths, that are fingerprinted and built as a graph. These points, called nodes, are then con-nected with each other by edges with different lengths denoting the distance between
