A Modular and Open Software and Hardware Architecture for Internet of Things Sensor Networks

UNIVERSITY OF SOUTHAMPTON

FACULTY OF ENGINEERING AND PHYSICAL SCIENCES

Mihaela Apetroaie-Cristea

Supervisor: Prof. Simon J. Cox and Dr. Steven J.J. Ossont

June 25, 2020

iii

UNIVERSITY OF SOUTHAMPTON

ABSTRACT

FACULTY OF ENGINEERING AND PHYSICAL SCIENCES

A Modular and Open Software and Hardware Architecture for Internet of Things Sensor Networks

by Mihaela Apetroaie-Cristea

We are experiencing a new industrial revolution, a cyber-physical systems revolution. The Internet of Things (IoT) is at the core of this development, and it is changing the way we perceive the world around us, impacting both business and technology.

Smart cars, smart thermostats, home automation hubs, smart lighting, and smart weather stations are common technologies met in most cities and households. The number of these devices is going to increase even more, and it is predicted to reach billions over the next few years. Although the IoT technology has reached maturity, we are still unprepared for the large number of devices predicted to reach the world in the near future. Managing high numbers of IoT devices requires stable infrastructures for deployment and management. It also requires creating sustainable infrastructures to minimise the impact on the environment.

In this thesis, we hypothesise that using flexible, open, modular, and reconfigurable hardware and software architectures at the base of smart city infrastructure can increase device longevity and minimise device management complexity at scale, while promot- ing sustainable development. The main contributions are: (1) identification of design requirements for building the next generation IoT device (2) reference architecture for flexible, modular IoT devices, (3) a novel, modular, open-source sensor board for building plug-and-play smart devices, allowing for complete removal/replacement of sensors and computing module, (4) a novel, modular, open-source software architecture, including: minimal Operating System (OS), over the air (OTA) updates, containerisation and remote device management, and (5) demonstration using a real-life application of environmental monitoring. The reference architecture presented in this thesis provides a robust, persistent, and reliable long-term solution for IoT deployements that addresses concerns regarding the negative impact of IoT on long term sustainable development.

Contents

Acknowledgements xi

Declaration of Authorship xiii

1 Introduction1 1.1 Thesis structure...... 3

2 The Internet of Things in our lives7 2.1 Towards ubiquitous computing...... 8 2.1.1 Sustainability...... 8 2.1.2 Internet of Things to address global goals...... 8 2.1.3 Internet of Things in our cities...... 9 2.2 Internet of Things hardware technologies...... 12 2.2.1 Single Board Computers...... 12 2.2.2 Sensors...... 12 2.3 Enabling technologies...... 14 2.3.1 Open Sensors Platforms...... 14 2.3.2 Scalability...... 15 2.3.3 Networking...... 18 2.3.4 Operating Systems and Unikernels...... 19 2.3.5 Over the air updates...... 22 2.3.6 Containerisation...... 24 2.4 Internet of Things applications...... 26 2.4.1 Air Quality monitoring...... 26 2.4.2 Plug and Play platforms...... 27 2.5 Research Questions and Objectives...... 29

3 Indoor positioning system 33 3.1 Indoor localisation system based on low-cost commodity hardware.... 34 3.1.1 Introduction...... 34 3.1.2 Design of the Indoor Localisation System...... 35 3.1.3 Preliminary Testing...... 36 3.1.3.1 Methods...... 36 3.1.3.2 Results...... 37 3.2 Further assessment of the system performance...... 38 3.2.1 Methods...... 39 3.2.2 Discussion and analysis of the results...... 39 3.3 Conclusions and future work...... 45

v vi CONTENTS

4 Generic IoT device for an environmental monitoring use case 49 4.1 Development...... 49 4.2 Theoretical use case - Southampton Smart City...... 50 4.3 Air quality monitoring...... 52 4.4 Preliminary testing...... 53 4.4.1 Implementation...... 53 4.4.2 Data...... 54 4.4.3 Security and Privacy...... 54 4.4.4 Outreach...... 57 4.5 Lessons learned...... 58

5 Hardware architecture 61 5.1 Introduction...... 61 5.2 Motivation...... 61 5.3 Proposed Solution...... 62 5.4 Environmental monitoring example...... 64 5.5 Face validation - results and conclusions...... 65 5.6 Known issues and limitations...... 69

6 Software architecture 71 6.1 Introduction...... 71 6.2 Requirements...... 73 6.3 Operating Systems...... 73 6.4 Remote device management...... 75 6.5 Over the air updates...... 75 6.5.1 OSTree...... 76 6.6 Containerisation...... 78 6.6.1 Applications in containers...... 79 6.7 Server-side requirements and considerations...... 79 6.8 Power...... 80 6.9 Implementation details - other technologies...... 81 6.10 Face validation - results and discussion...... 82 6.10.1 Implementation details...... 82 6.10.2 Experiments...... 83 6.10.3 Security and privacy...... 86 6.10.4 Known issues and limitations...... 87

7 Conclusions 91

8 Future work 95

A PiSEB v1.0 Eagle Schematics 99

B PiSEB v2.0 Eagle Schematics 109

References 119 List of Figures

1.1 Hype Cycle for Internet of Things [148]...... 2 1.2 IoT continous development...... 3 1.3 Proposed hardware and software modular architecture, where S represents a sensor...... 5

2.1 The United Nations Global Goals adopted in 2015 [54]...... 8 2.2 BalenaOS Architecture...... 21 2.3 Containarisation software architecture...... 24 2.4 Sandboxing software architecture...... 25

3.1 Locator node...... 35 3.2 Section of the oﬃce area...... 37 3.3 Testing area layout...... 37 3.4 Graph illustrating the error variation at 17 measurement points...... 38 3.5 The error variation when three locator nodes have been considered.... 38 3.6 Variation of the position estimation errors at the measurement points for the indoors experiment...... 40 3.7 Variation of the position estimation errors at the measurement points for the outdoors experiment...... 40 3.8 Variation of the error with ideal solution scoring for the indoor measurements 41 3.9 Variation of the error with ideal solution scoring for the park measurements 42 3.10 Represenation of the solution interval as the intersection between the rings to include the signal strength noise parameter ∆ ...... 43 3.11 Radiation pattern of the omnidirectional, high-gain antenna used for this project [143]...... 44

4.1 Map of Southampton...... 51 4.2 Device architecture for the preliminary test...... 53 4.3 Preliminary test SO2 and NO2 data...... 55 4.4 Preliminary test PM2.5 data...... 55 4.5 Preliminary test temperature data...... 56 4.6 Preliminary test pressure data...... 56 4.7 Example of the charts used in the preliminary testing...... 58

5.1 Reference hardware modular architecture, where S represents a sensor.. 63 5.2 PiSEB development board [12] designed as part of this research, where the continous line delimitates the microcontroller (pycom) and SBC (Rasp- berry Pi) interfaces...... 63 5.3 The hardware used for the environmental sensor prototype...... 65

vii viii LIST OF FIGURES

5.4 Reference hardware modular architecture, where S represents a sensor.. 67

6.1 Reference modular architecture showing the main technologies used for our software implementation...... 73 List of Tables

2.1 Gas sensors costs and performance metrics...... 15

3.1 Cost and accuracy of top indoor positioning systems on the market.... 35 3.2 Price of locator node...... 35 3.3 Requirements...... 47

4.1 The sensors chosen for the ﬁrst version of the generic IoT device..... 50 4.2 Methods for achieving the design requirements - customisation, expansion, maintenance and accessibiliy- hw represents hardware and sw represents software...... 60

5.1 The sensors chosen for the ﬁnal version of the generic IoT device..... 66 5.2 Hardware face validation results...... 68

6.1 OSTree-based ﬁlesystem...... 77 6.2 Software face validation results...... 85

Acknowledgements

This work is supervised by Prof. Simon J. Cox and Dr. Steven J.J. Ossont. Their guidance and support have been extremely valuable for the work presented in this thesis. I would like to thank my supervisors for being there for me every step of the journey, believing in me and getting out of their way to help me succeed.

Many thanks also to Dr. Mark Scott, Dr. Phillip Basford, Nana Okra Kwadwo Abankwa, Dr. Lasse Wollatz, Florentin Bullot, and Andrew J. Poulter for helpful feedback during our weekly group meetings and support over the last four years.

I would also like to thank my family and friends for the moral support and for believing in me.

I would like to dedicate this work to the memory of my grandfather, Dumitru Apetroaie, and Layla Apetroaie-Cristea.

Declaration of Authorship

I, Mihaela Apetroaie-Cristea , declare that the thesis entitled A Modular and Open Software and Hardware Architecture for Internet of Things Sensor Networks and the work presented in the thesis are both my own, and have been generated by me as the result of my own original research. I conﬁrm that:

• this work was done wholly or mainly while in candidature for a research degree at this University;

• where any part of this thesis has previously been submitted for a degree or any other qualiﬁcation at this University or any other institution, this has been clearly stated;

• where I have consulted the published work of others, this is always clearly at- tributed;

• where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work;

• I have acknowledged all main sources of help;

• where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed myself;

• parts of this work have been published as: (please see Supporting publications section)

Signed:......

Date:......

xiii

LIST OF TABLES xv

Supporting Publications

Some of the work presented in this thesis has been also published in:

• PLOS ONE Apetroaie-Cristea, M., Ossont, S.J.J., Basford, P.J., Bulot, F.M., Scott, M., Cox, S.J.. An example architecture for managing distributed sensor networks at software and hardware levels. PLOS ONE Journal, 2020. submitted, under review.

• MDPI Sensors Journal Johnston, S.J., Basford, P.J., Bulot, F.M., Apetroaie-Cristea, M., Easton, N.H., Davenport, C., Foster, G.L., Loxham, M., Morris, A.K. and Cox, S.J. City Scale Particulate Matter Monitoring Using LoRaWAN Based Air Quality IoT Devices. MDPI Sensors. 19(1), 2019 (pp. 209 - 229).

• Global Internet of Things Summit (GIoTS) Johnston, S. J., Basford, P. J., Bulot F. M J., Apetroaie-Cristea M and Cox, S. J. IoT deployment for city scale air quality monitoring with Low Power Wide Area Networks, Global Internet of Things Summit (GIoTS). IEEE, 2018 (pp. 1-6).

• IEEE World Forum on Internet of Things (WF-IoT) Johnston, S.J., Basford, P.J., Bulot, M.J., Easton, N.H.C., Foster, G.L., Loxham, M., Apetroaie-Cristea, M, Morris, A.K.R, Cox, S.J. Testing Smart City environmental monitoring technology using small scale temporary cities. World Forum on Internet of Things (WF-IoT). IEEE, 2019 (pp. 578-583)

• Nature Scientific Report Bulot, F.M., Johnston, S.J., Basford, P.J., Easton, N.H., Apetroaie-Cristea, M., Foster, G.L., Morris, A.K., Cox, S.J. and Loxham, M. Long-term field comparison of multiple low-cost particulate matter sensors in an outdoor urban environment. Scientific reports 9. Nature, 7497 (2019), doi:10.1038/s41598-019-43716-3

• ISC High Performance 2016 23rd of July 2016 Poster + Presentation

• Book Chapter Johnston, S. J., Apetroaie-Cristea, M., Scott, M., and Cox, S. J. Applied Internet of Things. In Buyya, R. and Dastjerdi, A. V., editors, Internet of Things Principles and Paradigms, Chapter 15. Elsevier, 2016 (pp. 277-297)

• Ubicomp 2016 Poster + UbiComp 2016 Adjunct Proceedings + ACM Digital Library Apetroaie-Cristea M, Johnston, S. J., Scott, M., and Cox, S. J. (2016). Low-cost indoor positioning system based on commodity hardware. ACM, 2016 (pp. 13-16). xvi LIST OF TABLES

• World Forum on Internet of Things 2016 Johnston, S., Apetroaie-Cristea, M., Scott, M., Cox, S. (2016). Applicability of commodity, low cost, single board computers for Internet of Things devices. In World Forum on Internet of Things (WF-IoT). IEEE, 2016 (pp. 1-6). Chapter 1

Introduction

The Internet of Things (IoT) introduces the concept of smart objects or things that are interconnected, uniquely addressable, able to cooperate with each other, and perform tasks that would beneﬁt society. A dynamic area that captivates the attention of both industry and academia, some consider IoT the second technological revolution after the invention of the personal computer [35] and the fourth industrial revolution [128].

The term Internet of Things is relatively new [15], but its core areas and topics are met in literature from the early times of the computer. One of the main sub-fields of IoT - ubiquitous computing - is met in research literature and projects from the late 1980s. One example of such a project is Biosphere II [40], built over three years starting in 1987, an ecological life-support system with the scope of understanding the interaction between Earth’s surface and the atmosphere. Computer systems were embedded in the experimental research area for administrative support, communication, and monitoring of ambient conditions. Weiser [154], who defined the term ubiquitous computing, was considering that the computers should be embedded everywhere throughout the physical environment, to help humans in a pervasive way and not remain the main focus of their attention. He also identified the main issues that had to be addressed for his idea to become a reality. These issues are the cost of computers, power consumption, the need for a wireless network to accommodate hundreds of high-speed devices, the need for a new network protocol, privacy issues. Nowadays, computers have decreasing power consumption and increasing computational power, smaller sizes, lower prices, the IPv6 (Internet Protocol version 6) can accommodate 5x1028 devices for every person in the world, while new security and privacy solutions are under continuous development.

All of these technological advances are leading to accelerated development of IoT technologies, which are becoming a ubiquitous part of our environment, like Weiser [154] predicted. Gartner [55] predicts that the number of Internet of Things (IoT) devices is going to increase to reach tens of billions in the near future. With this number of devices, IoT will have a strong inﬂuence on society and will change the way people perceive the

1 2 Chapter 1 Introduction

Figure 1.1: Hype Cycle for Internet of Things [148]. objects around them. Smart cities, smart buildings, smart homes, smart cars, smart manufacturing, smart transportation, and smart business management are just a few examples of technologies impacting our society.

According to Velosa [148], the IoT already reached maturity and it is situated in the productivity area on the hype cycle, Figure 1.1. Cities such as Amsterdam, London, San Francisco, Oslo, and Barcelona are already building smart infrastructures that benefit from these technological advances. Amsterdam has smart lighting, smart playgrounds, encourages circular businesses and energy-saving [105]. London is planning on building a smart infrastructure with an emphasis on transportation and resource-saving [56]. San Francisco is famous for the smart parking infrastructure [80]. Oslo benefits from smart parking and street lightning [32]. Barcelona has 500 km of fibre optic network, free public WiFi coverage, and smart lightning [20]. All of these cities are smart cities because they use technology to improve the living conditions, such as sensors and actuators, to collect data that is used to improve aspects of the daily routines, save resources and improve costs.

Hardware capabilities are improving, while the price and physical size are signiﬁcantly decreasing. For example, the introduction of the Raspberry Pi Zero at the beginning of 2016 for $5 that is half the size of the ﬁrst Raspberry Pi model of 2012 and has better Chapter 1 Introduction 3

Smarter Cities

Increased Management Technological Complexity Advances

Smart Cities Continuous Development

Environmental Prices Drop Impact

Community More, Adoption Smarter Devices

Figure 1.2: The continuous development of technology and its impact on smart cities

CPU clock and RAM. Raspberry Pi 4 Model B was introduced on the market this year (2019) and has four cores, more than double the CPU clock frequency and up to eight times more RAM than the Raspberry Pi 1 Model A, which was introduced on the market in 2012 for the same price of $35. This evolution is enabling signiﬁcant technological progress; it leads to new research projects and development to be made in IoT.

With billions of IoT devices predicted to reach consumers over the next few years, the world as we perceive it will change drastically. An increased number of IoT devices can lead to increased costs, complexity, landfill, and clutter. Hence, finding ways of sustainably managing these devices at large scale is essential for the future of IoT. [56] revealed in the 2050 smart city plans for London that re-using existing infrastructures and developing infrastructures that serve multiple purposes is essential for smart cities as it reduces costs, pollution, and saves resources. The conjecture for this work is that using modular hardware and software, we are able to design an IoT device that is reconfigurable after deployment, and it can adapt to its environment. The next chapters explore the literature, the requirements for building such a device, and present a device architecture designed and built using these requirements, which is validated through an environmental monitoring use case.

1.1 Thesis structure

This thesis has six chapters. This is the ﬁrst chapter, the introduction. It presents the structure of this thesis and the scope of this work.

Chapter2, Internet of Things in our lives, presents the current status of the Internet of Things and general topics of interest in the area, as an extension to the work presented 4 Chapter 1 Introduction in [69]. This chapter gives a better understanding of the current state of the technology, gaps in IoT device architectures and infrastructures, and the research questions and objectives addressed in this work.

Chapter3 presents an indoor positioning system that has been developed based on low- cost commodity hardware as part of this research. The Chapter consists of a conference paper that was presented at the UbiComp2016 [13]; it also presents data that has been collected to assess the performance of the system further. The work presented in this chapter represents the ﬁrst stage of this research, which helped with understanding the main issues in deploying and managing IoT devices at scale. The main scope of this chapter is to investigate the requirements for an open IoT device architecture that can adapt to technological developments and allows re-use of infrastructure.

Chapter4 presents an environmental monitoring example that was designed and built for an outreach project in order to explore IoT architectures and answer the research questions in depth.

Chapter5 presents a generic IoT device. The main component of the device is a generic plug and play board, developed using the HAT characteristics [90], the PiSEB [12]. This Chapter also presents the hardware implementation of a working environmental monitoring device example to validate the proposed solution.

Chapter6 presents the generic, plug, and play software architecture that was developed for this work to fulﬁll the role of a working reference implementation and a skeleton for developing new applications. Our implementation is targeted to our device in particular, but it can be easily adapted to work in entirely diﬀerent environments and devices. This Chapter also presents the software implementation of a working environmental monitoring device example to validate the proposed solution.

The last two chapters, Chapters7 and Chapter8, present the conclusions and future work for this research. Chapter 1 Introduction 5

Minimal OS

App 1 ... App N

Remote Over the air updates Container engine management client

>_ Kernel Flexible, modular software

Flexible, modular Processing/Computing board hardware

Plug&play sensor/actuator Storage Wireless comms comms extension

S1 S2 S3 S4 ... Sn

Figure 1.3: Proposed hardware and software modular architecture, where S represents a sensor

Chapter 2

The Internet of Things in our lives

The Internet of Things (IoT) is evolving at a high rate, from smart cities [96] to home automation [119], the idea behind IoT is the pervasive presence around us of various sensors and devices that send and receive data, are able to cooperate with each other and perform tasks that would lead to automation, increased eﬃciency and better management of processes.

IoT highly impacts our living, contributing to increased quality of life [54]. Cities around the world are adopting the IoT emerging technologies to build infrastructures that help saving resources, improve costs, and beneﬁt the health [96, 105, 32]. All of these are possible due to great hardware and software advances [135], which allow for low-cost sensors and devices to be embedded into our everyday lives, taking us closer to achieving what Weiser [153] envisaged.

Sensor networks are at the core of IoT, street lighting, and air quality monitoring are examples that prove their signiﬁcance to the area studied in this work [16].

With the predicted increase of IoT devices that are going to be deployed around the world in the near future, more research is required for achieving device scalability. Find- ing solutions to ease device interoperability, developing operating systems that facilitate operations on resource-restricted devices in out-of-reach constrained environments is essential at this stage. Over the air, secure updates are also an essential part of IoT, ensuring devices’ reproducibility, ease of management, and deployment.

In this chapter, we discuss various aspects of state of the art in IoT and consider both the technologies involved and the challenges being tackled.

7 8 Chapter 2 The Internet of Things in our lives

Figure 2.1: The United Nations Global Goals adopted in 2015 [54]

2.1 Towards ubiquitous computing

2.1.1 Sustainability

Every year, nearly 50 million tonnes of e-waste are produced globally, out of which approximately 40 million tones end up in landﬁll, and it is expected that by 2021 the annual e-waste volume will surpass 52 million tones [115]. A signiﬁcant part of this e- waste is generated by IoT devices. IoT has a positive impact on sustainability, showing a strong correlation with 11 of the 17 Sustainable Development Goals (SDGs) [111]. IoT negatively impacts on responsible consumption and production, the 12th SDG [57]. The UN has proposed tackling this issue by creating a circular economy, ensuring we get the most out of the deployed devices. For example, London is planning on re-using existing devices and infrastructure for providing new services [56] and to create an infrastructure that serves more purposes to minimise costs, save resources and reduce pollution for building new infrastructure. The main focus has been on developing new IoT services, and there has not been enough research done in the area regarding these devices after they become out of date or break.

Projects such as Freecycle [140] are an excellent initiative for minimising landﬁll. There is still a need to develop a very eﬃcient method of re-using hardware that will accommodate the forecast of increase in IoT devices.

2.1.2 Internet of Things to address global goals

In September 2015, the United Nations (UN) adopted 17 Global Goals. The goals are illustrated in Figure 2.1. IoT is a technology that can be used to address these goals, and some of the work in the domain shows that the process has already started. Chapter 2 The Internet of Things in our lives 9

Internet of Things applications in the health domain, such as monitoring elderly people [45] or health monitoring devices that can be used from home to give a better insight of patients health at the comfort of their homes [121] are just a few systems that are very popular nowadays and are helping towards reaching the UN Global Goals.

IoT is contributing to advances in hardware and software. These lead to developing better education means, providing educators and students with better educational platforms [79] and more resources [42].

Low-cost sensors can be used in a wide range of areas, such as water, weather, and air quality monitoring [8, 68], to give us information that can help increase the quality of life. Smart monitoring devices, such as smart meters, smart sockets, and light sensors, can decrease the usage of water, energy, and similar valuable resources. Solar energy storage and sharing are also examples of applications that help decrease resource waste. Smart irrigation [52] and smart lighting are also reducing waste.

Smart cities infrastructures [56, 96] give birth to sustainable cities [105] with responsible goods consumption and circular business infrastructures, where recycling and resource sharing are reducing waste and littering.

Devices tracking our goods [137] and better software security solutions [117] are also contributing towards decreasing criminal activities.

2.1.3 Internet of Things in our cities

Cities across the world are embracing the IoT technologies. This section presents some of the most popular smart city initiatives.

Singapore

Singapore started the Smart Nations program in 2014 [107]. The idea behind the program is to create a distributed network of sensors across the city that will be used for diﬀerent applications, which do not have to be known before the deployment of the sensors. Multiple cameras have been deployed to monitor littering, bus travelers’ smartphones have been used to monitor street maintenance level, and motion sensors have been used to monitor the elderly [96]. Monitoring is also done in the areas of public transportation, air quality, and energy consumption. The data portal is open to developers and has a public API [66].

There is a plan for the future to collect the data from sensors centrally to store information on building architecture and weather conditions.

The main concern of this project is the protection of privacy and security. For example, under Singapore law, any decision to use the data from the sensors for law enforcement 10 Chapter 2 The Internet of Things in our lives does not need court approval. This can easily lead to privacy invasion. Creating ethical frameworks to solve these problems is still under development.

Amsterdam

In 2016 Amsterdam won Europe’s Capital of Innovation award by the [50]. The plan [105] is to build data-driven city management. The projects that will be developed as part of Amsterdam Smart City are concentrated around:

• Infrastructure and technology - using IoT for crowd management and smart, dynamic pitch lighting on the Amsterdam ArenA. Green playground, where the whole family can enjoy ﬁtness equipment that illuminates when someone exercises that also has illuminated benches in the evenings and augmented reality characters for entertaining.

• Energy, water, and waste - with projects such as storage and trade of solar sur- plus energy through home batteries, sharing energy between households to obtain energy-neutral neighbourhoods.

• Mobility - for example, bicycle kits that would make bikes connect with each other, collect data, and act as an anti-theft system.

• Circular city - projects such as encouraging local companies to use organic waste to develop new products to reduce sourcing, transportation, and waste management costs or building a circular data platform with multiple ﬂows.

• Governance and Education - for example, the project City Protocol that aims to achieve city interoperability.

• Citizens and living - for example, citizens science projects, such as measuring weather conditions and air quality.

Although most of these projects are still under development, the Amsterdam smart city project is an example of a complex and highly data-driven city architecture that will become a reality in the near future.

Barcelona

Barcelona is one of the exemplary smart cities in Europe. The most outstanding technological advances in Barcelona are 500 km of ﬁbre optic network, 670 WiFi hotspots at a maximum distance from each other of 100 m that provide free city-wide WiFi, 19,500 smart meters that monitor and optimize energy consumption, smart parking, digital bus stops with updates on bus location, USB charging stations, free WiFi and tools to help riders learn more about the city [20]. Chapter 2 The Internet of Things in our lives 11

The Barcelona Lightning Masterplan that uses technology to enhance the eﬃciency and utility of city lampposts with more than 1100 lamp posts that have LED and brighten when pedestrians are in close proximity. They also are part of the WiFi network that provides free WiFi across the city and have sensors that collect data on air quality and monitor weather conditions for determining the amount of irrigation required for parks.

These create Barcelona’s sensor network that is relayed through the Sentilo platform [122], which was created speciﬁcally for Barcelona, but it was made open-source in an eﬀort to encourage other cities to join Barcelona’s example of creating a smart city.

London

London is another example of a smart city. The open data platform London Datastore [41] has a public API and stores data on jobs and economy, transport, environment, community safety, housing, health, and more. London adopted transportation innovation technologies such as number plate recognition for congestion charge, WiFi on the Underground, and uses new technologies to reuse waste heat. There are some citizen science projects such as air quality monitoring [43] and weather monitoring logged to the [23]. London Air [151] is a project that aims to inform London citizens on the air quality within the city.

Breathe Heathrow [112] is another initiative of monitoring air quality and noise. Sensors are placed in people’s gardens in an attempt to inform the population about the potential dangers they are exposed to around Heathrow airport.

London is a centre for technological advances, and multiple start-ups and companies are showcasing their technology.

London has committed to a development plan for 2050, which aims to improve London’s infrastructure, with a focus on transportation, creating a circular economy, improved green infrastructure, energy and water, and digital connectivity [56].

San Francisco

San Francisco is renowned for the number of start-ups that are born in the city, which is why it is at the core of technological advances. From all these technologies, San Francisco is famous for its smart parking initiative [80].

Oslo

Oslo is another city that has plans for becoming a smart city. At the moment, they have parking monitoring and smart street lighting. They also have initiatives to assist sick and elderly patients and want to reduce greenhouse gas emissions by 50% [32]. 12 Chapter 2 The Internet of Things in our lives

2.2 Internet of Things hardware technologies

The IoT development is driven by signiﬁcant increases in hardware capabilities and cost reductions. This section brieﬂy summarises the most important hardware technologies that stay at the base of IoT and have been standing as technological pillars for the IoT development during the period of this research (2015 - 2019), with emphasis on the main applications and sensors that form the base of smart cities.

2.2.1 Single Board Computers

One of the most common IoT development boards is the Raspberry Pi - a series of credit-card size, single-board computers. The ﬁrst Raspberry Pi was introduced on the market in 2012 at a target price of $35 and features the Broadcom BCM2835 system on a chip (SoC), a 700 MHz single-core ARM1176JZF-S Central Processing Unit (CPU) and Broadcom VideoCore IV @ 250 MHz Graphics Processing Unit (GPU). The latest version is Raspberry Pi 4 Model B that was released on the market in July 2019. It features the Broadcom BCM2711 SoC, a 1.5 GHz quad-core A72 64-bit CPU, a Broadcom VideoCore VI @ 500 MHz GPU and built-in WiFi and Bluetooth capabilities [135].

Raspberry Pi is not the only single-board computer that recently has emerged on the market. Companies such as Intel have released low-price single board computers, but there are also start-ups producing them, such as Pine64. A more detailed discussion about these boards, microcontrollers, and other releases in the area and their speciﬁca- tions can be found in the book chapter written during this research [69].

Low-cost single board computers and sensors have enabled high performance computing [42] and other projects [13,3] that otherwise would be expensive and out of reach for most consumers.

2.2.2 Sensors

Sensor costs are signiﬁcantly decreasing; for example, the price of a WiFi or Bluetooth dongle can be as low as $1. Gyroscopes, accelerometers, magnetometers, and GPS are widely available, low-cost, and embedded onto the majority of personal devices on the market. This enables new research projects, such as indoor positioning [77].

Extensive research is also done to achieve higher performance, for example, in the detection of gases [19].

The hardware developments have a signiﬁcant impact on the Internet of Things enabling new research perspectives and advances. Chapter 2 The Internet of Things in our lives 13

Analysing the smart cities’ initiatives and applications, it can be noticed that there are a common trend and a general agreement in the nature of the future smart cities applications.

Common sensors in a Smart City

One of the most common applications met in the future smart city is weather monitoring. Either citizen science projects or academia projects [68], weather stations seem to reach state of the art with highly accurate low-cost sensors and community platforms [23] that collect and analyse the data.

Smart transportation is another common theme among smart cities with live updates on bus locations, automatic sensing of passenger distribution in trains and WiFi hotspots in public transportation. Automatic recognition of plate numbers for congestion charges and counting cars on the motorway are some of the most common applications. For these applications, technologies such as WiFi, Bluetooth, GPS, cameras, and ultrasound are needed.

Smart parking is a widespread application. For example, the San Francisco parking system is based on a device that is drilled into the parking lot and contains a magnetometer, battery, processor, and radio communication for transmitting data [80].

Sustainability is another signiﬁcant area that has applicability within the IoT area. Smart lighting, smart water meters, smart waste management are some of the applications under development in the area, and sensors such as motion, light, cameras, and long-range, low power radio transmitters are essential sensors needed for these applications.

Noise detection is also a popular application for smart cities. For example, monitoring the noise levels within the city and making open-source maps with noise pollution. ShotSpotter is a company that uses microphones deployed across cities to detect gunshots [34]. For these applications, sensors such as microphones are necessary.

Monitors for the structural integrity of buildings is another popular application [129]. Sensors such as accelerometers are necessary for this type of application.

Global warming [78] and increased pollution within the cities [97] are big concerns in our society. Air quality became one of the main concerns within the big cities due to health implications [30], which is why air quality monitoring devices are going to be embedded within all the future smart cities [105]. The most commonly monitored gases are Nitrogen Dioxide and Sulphur Dioxide. Particulate matter is also commonly monitored [130].

Gas Sensors

High-end air quality monitoring sensors are expensive [44]. With prices greater than £10, 000, having a large number of such devices is infeasible, while having just a few of them cannot give a good description of the environment. This is why it is important to 14 Chapter 2 The Internet of Things in our lives have good and reliable low-cost air monitoring devices that would give sensitive results and would complement the few high-end devices that are already deployed in most cities.

The current generation of low-cost air quality monitoring devices (under $20) do not give reliable results, they do not give absolute readings, their accuracy is lower than the maximum healthy amount deﬁned by Defra Directive 2008/50/E [29], and their range is not relevant to these values being sensitive to very high volumes of gases [83, 76], which is why they are not considered in this work.

According to Defra Directive 2008/50/EC [29], the threshold for Sulphur Dioxide is 500µg/m3, which means approximately 0.188 ppm, for three consecutive hours over 100km2 area and the threshold for Nitrogen Dioxide is 400µg/m3, which means approximately 0.21 ppm, for three consecutive hours over 100km2 area. According to [157] the Particulate Matter 2.5 (PM2.5) should not exceed 10µg/m3 as annual mean and 25µg/m3 as 24-hour mean. The PM10 should not exceed 20µg/m3 as annual mean and 50µg/m3 as 24-hour mean.

Hence, the air quality monitoring sensors should be sensitive enough to sense values within these thresholds. Table 2.1 shows some of the low-cost sensors with sensitivity and range that allow to detect air pollutants within the oﬃcial healthy limits and could reliably be used as a reference for determining the air quality. The accuracy of these sensors is not high enough to generate data showing the exact pollution levels, but they can be used to indicate when the pollution levels change. Considering the current state of hardware and software evolution, it is expected that similarly accurate sensors will be available for under $20 in the near future.

2.3 Enabling technologies

2.3.1 Open Sensors Platforms

The IoT sensor data can be sent for visualization and sharing with the public to online platforms. This subsection exempliﬁes the most popular open-source platforms for data storage and visualization.

• Sentilo [122] is an open-source data management platform initially built for the smart sensors in Barcelona. Other cities across diﬀerent countries have adopted the platform. For example, in Winchester, Hampshire, weather data and road temperature data is logged and can be visualised with Sentilo.

• The Things Network [142] is a community network that enables low-power devices to use long-range, low power radio frequency protocol, LoRaWAN, and Bluetooth for short-range. Chapter 2 The Internet of Things in our lives 15

Table 2.1: Gas sensors meeting the requirements for this project, containing costs and performance metrics; the cross-sensitivity is a measure of how much the values read by the sensor are inﬂuenced by other substances than the measured ones. Please note that the costs are valid at the time of this writing (2019) and might change in time

Distributor Gas Model Resolution Range Half Price Cross- Life ($) sensitivity Plantower PM PMS1003 1 ppb 0 - 500 25 high µg/m3 Euro-gasman NO2 4-NO2-20 0.1 ppm 0 -20 2 yrs 45 medium ppm Alphasense NO2 A4-series 0.1 ppb 0 - 20 2 yrs 52 medium ppm Alphasense SO2 A4-series 15 ppb 0 - 50 2 yrs 52 medium ppm Alphasense NO2 B4-series 0.1 ppb 0 - 20 2 yrs 55 medium ppm Alphasense SO2 B4-series 5 ppb 0 - 100 2 yrs 55 medium ppm Euro-gasman SO2 4-SO2-20 0.1 ppm 0 -20 2 yrs 57 medium ppm Sensortech SO2 EC4-20-SO2 0.1 ppm 0 - 20 1 yrs 88 medium ppm Sensortech NO2 EC4-20-NO2 0.1 ppm 0 - 20 1 yrs 103 medium ppm Alphasense PM OPC-N2 0.38 to 0.84% 277 high 17 ppb @ 106 part./L Libelium NO2 NO2-A43F 0.1 ppm 0 - 20 2 yrs 290 medium ppm Libelium SO2 SO2-A4 0.1 ppm 0 - 20 2 yrs 290 medium ppm

• Open Sensors [114] is another community platform that allows users to log, visu- alize, and share data.

• WOW Met Oﬃce [23] is an open-source platform that allows citizens to log data from their own weather station devices.

• Freeboard [2] is an open-source platform for real-time data visualization, beneﬁting from a drag and drop interface.

• Plot.ly [116] is an open-source visualization library and online chart creation tool.

2.3.2 Scalability

The Internet of Things area is evolving very fast, and with the high increase of IoT devices that are predicted to reach the consumers in the next years, it is imperative to consider 16 Chapter 2 The Internet of Things in our lives further expansions of a system before deploying. When the number of devices is large, scalability is problematic at diﬀerent levels, including data transfer and networking, data processing and management, and service provisioning [101].

Many IoT systems can be represented as client-server architectures, where clients are the devices deployed in the ﬁeld, and the server is responsible for data collection and device management and monitoring. Sometimes the server is also responsible for passing messages between devices and sending actions to actuators.

There are two types of scalability: scalability on the server-side and scalability on the client-side.

Scalability on the client-side deals with hardware and software at the device level, such as power consumption, hardware durability, commissioning, networking, hardware maintenance, and reliability. These are presented in the next sections as they are a signiﬁcant part of this work.

As the number of devices in a system grows, the server can easily become a bottleneck. There are many ways to scale a server, and there are software solutions and commercial cloud services that oﬀer easy to use ways to build robust, scalable servers. In IoT, the biggest scalability concerns are around big data, namely having to support a large volume of data, sometimes coming at a high velocity. In systems with many types of sensors and other data sources, the data also comes in a wide variety of ways [37].

This subsection presents some of the solutions that can help achieve scalability on the server-side.

Designing a server (or more) to scale for supporting a large number of clients at the same time is usually addressed by a load balancer and more replicas of the server software. We are not going into the details of scaling servers, as this is not the main focus of this work. We will instead describe some common data-related issues that can arise while developing IoT systems.

One issue is picking the right data storage mechanism. There are plenty of choices, from generic relational databases to no-SQL databases specialised for different types of data to simply using files on the filesystem. There is no one size fits all solution, and we will describe a few options.

• Relational databases are digital databases that store data based on the relational model deﬁned by Codd [39]. The data is organised in a set of tables, from which the data can be accessed or organised without the need for reorganising the database tables. The relational databases are written in SQL (Structured Query Language), which is the standard language for managing relational databases. The most commonly met relational databases are: SQLite [70], MySQL [59], PostgreSQL [104], Oracle [102]. Chapter 2 The Internet of Things in our lives 17

• Document databases are databases designed for storing, retrieving and managing semi-structured data. The most popular document databases are: MongoDB [38], CouchDB [9], RavenDB [84].

• Time Series Database (TSDB) is a software system designed for handling time series. Frameworks such as Inﬂuxdata[108], OpenTSDB [134], Prometheus [118] are using TSDBs to manage large amounts of data without losing granularity and provide scalability. TSDB is ideal for large amounts of time-series data when ﬂat databases are not a viable option due to limited storage and processing capacity.

Another issue is data processing at scale. A widely used software library and starting point for addressing this is Hadoop [147].

Apache Hadoop is an open-source software library for distributed computing. It is a highly-available service able to scale from single servers to thousands of machines, oﬀering local computation, storage, and failure detection at the application layer. It includes:

• Hadoop Common with common utilities supporting other Hadoop modules

• Hadoop Distributed File System (HDFS) that provides access to application data

• Hadoop YARN, a framework for job scheduling and cluster resource management

• Hadoop MapReduce, a YARN-based system for parallel processing of large data sets.

The software libraries and packages described above can help significantly in developing reliable IoT solutions. However, setting up and maintaining all of the required databases, data processing pipelines, and device management solutions takes a significant amount of time and effort. Commercial solutions that offer easy to use and quick to set up systems for reliably managing big data are available from companies such as Amazon, Google, and Microsoft. These cloud-based solutions give developers the chance to build IoT applications without managing complicated server infrastructure. Below are some IoT-focused cloud platforms.

• Microsoft Azure IoT Suite [53] is a platform-as-a-service (PaaS) built on top of Microsoft Azure that oﬀers device re-provisioning, ownership transfer, secure device management and device end-of-life management for IoT.

• Microsoft IoT Central [138] is an end to end software-as-a-service (SaaS) platform built on top of Microsoft Azure IoT suite . It is a fully managed SaaS addressed to IoT developers without cloud expertise that allows quick deployment and management of IoT devices. 18 Chapter 2 The Internet of Things in our lives

• Amazon Web Services IoT [60] is a managed cloud platform with a software stack that enables connecting IoT devices to Amazon Web Services. The platform offers software tools that allow for ease of integration, secure communication, and management of devices with Amazon Web Services.

The cloud solutions provide us with server infrastructure, data storage solutions, and analytics frameworks. Web services providers such as Microsoft Azure [156], Amazon Web Services [67], Google Cloud Platform [75] oﬀer a wide range of analytics, computing, database, mobile, networking, storage, and web solutions.

The actual server application software is the glue between the IoT devices and the data storage and analytics. NodeRED [81] helps writing the server application, and also with on-device application software. NodeRED is a web-based service that runs on the platform of interest (i.e., Raspberry Pi). It presents the user with a graphical interface to control data ﬂow between modules. NodeRED comes with an extensive library of complementary modules for hardware communication, interaction with social media, and visualisation frameworks. It runs on Linux distributions, Mac OS X, and Windows.

2.3.3 Networking

Technologies such as LoRa [17] and Thread [95] provide networking stacks for IoT devices in diﬀerent scenarios, for large areas (e.g., city-wide coverage) and small areas (e.g., in a house or a building), respectively.

• LoRaWAN is a Low Power Wide Area Network (LPWAN) speciﬁcation intended for battery-operated wireless devices in regional, national or global networks. The standard provides interoperability, bi-directional communication, mobility, and localisation services. It operates at data rates between 0.3kbps to 50kbps, managed for each device employing an adaptive data rate (ADR) scheme to maximise the battery life of the end-devices and overall network capacity. Security is ensured at the network, application, and physical layers.

• Thread is an IP-based wireless networking protocol launched by Thread Group, that relies on low-power radio protocol called IPv6 over Low Power Wireless Per- sonal Area Networks (6LowPAN). Thread sends small amounts of data. Hence it has low power usage. It is also based on mesh networks that can scale to hundreds of devices without a single point of failure and involves "banking-class" encryption. As it is a networking standard, it works with high-layer standards, such as AllJoyn and IoTivity.

• Sigfox [159] is a Low Power Wide Area Network (LPWAN) where the devices send data through the SigFox network to a SigFox base station (gateway). The base Chapter 2 The Internet of Things in our lives 19

station then detects, demodulates, and reports the messages to the SigFox cloud across three channels, at least every 10 minutes

• ZigBee [73] is a wireless-based open, global standard used for personal-area networks targeted at low-power applications with infrequent data transmission needs. It operates on the 802.15.4 standard and enables wireless mesh networks with low- cost and low-power solutions. It has data transmission rates of up to 250kbit/s, up to 100m transmission range and it supports up to 65, 000 nodes. Millions of ZigBee- enabled products exist on the market today, including in smart homes, connected lighting, and the utility industry.

• Bluetooth Low Energy [58] is a low-range, low-power wireless technology designed to be used for monitoring and controlling applications. It operates in the 2.4 GHz Industrial Scientiﬁc Medical (ISM) band and deﬁnes 40 Radio Frequency (RF) channels with 2 MHz channel spacing. It uses single-hop communication and can be used for connecting large amounts of IoT devices.

2.3.4 Operating Systems and Unikernels

Internet of Things devices are generally resource-constrained and built to meet speciﬁc functions, unlike personal computers. Hence they can beneﬁt from more specialised OS distributions. Linux is the most popular base OS for IoT. Linux [132] is an open-source, Unix-like and mostly POSIX-compliant computer OS.

This section presents some of the OSs considered for the projects presented in this work.

• Raspbian [135] is a Linux-based OS developed for Raspberry Pi devices. The Debian-based OS has four versions: Wheezy, Jessie, Stretch, and Buster. The OS is speciﬁcally optimised for Raspberry Pi hardware and has more than 35,000 packages.

• DietPi [27] is a light OS for Single Board Computer (SBC), mainly built around Raspberry Pi. Its size can be as low as 400 MB, it is based on Debian Jessie, and it contains tools such as backup, cleaner, lightweight ssh server, automatic ﬁlesystem expansion.

• OpenWRT [51] is a Linux-based Operating System speciﬁcally designed to run on routers and Access Points (AP).

• TinyOS [82] is an open-source Operating System (OS) and platform designed for sensor networks. It is a flexible, application-specific OS that supports concurrent programs with very low memory requirements (many applications fit within 16KB of memory, and the core OS is 400 bytes) and efficient, low-power operation. It was designed to run on a generalized architecture where a single CPU is shared between 20 Chapter 2 The Internet of Things in our lives

application and protocol processing. It makes use of event-based programming and enables system-wide optimisation by providing coupling between hardware and software.

• Alpine [48] is a small-size Linux distribution - a minimal installation requires 130 MB storage for embedded systems. It has its package manager, apk, and OpenRC init system, script-driven set-ups. The OS comes with read-only ﬁle systems only, and any changes made within the ﬁlesystem is discarded at reboot unless committed to the system. The downside of this OS is that its package manager has a limited number of packages, and porting packages from other distributions is time- consuming. Furthermore, some packages require rebooting during installation.

• NixOS [46] is a GNU/Linux distribution, that runs on top the Nix package manager. The package manager can provide incremental OTA updates, which have the same functionality as OSTree [149].

• Yocto project [125] was developed based on the OpenEmbedded project and allows creating and modifying Linux distribution. The deployment can be done directly on the hardware or using SSH. The Yocto images are build using Bitbake. Bitbake is the task executor and scheduler used by the OpenEmbedded build system to build images. Bitbake also allows building multiple targets at the same time, where each target uses a diﬀerent conﬁguration. The image build can be done via the terminal or using the Yocto project web interface, Toaster. The project is popular, and it supports builds for a wide range of machines and software packages.

• Windows 10 IoT Core [53] is a a version of Windows 10 optimised for embedded devices. It has support for Raspberry Pi, Arrow DragonBoard 410c, and Minnow- Board MAX. However, it lacks the community support, like other Linux-based OSs have, and it has not reached maturity at the time of writing (2019).

Containerisation and sandboxing are becoming popular choices for IoT because they ease application deployment and scalability. Some of the most popular Operating Systems built with an emphasis on these technologies are:

• Ubuntu Snappy [61] is a small size OS designed for IoT devices. The main feature of this OS is that applications can be sent over the air in snap packages. A snap is a zip ﬁle that contains the application to be deployed and its dependencies with a description of how the application should be run and how to communicate with other software. The applications are sandboxed or containerised. This isolates them from the underlying system adding security to the system. Chapter 2 The Internet of Things in our lives 21

Figure 2.2: BalenaOS Architecture showing the main OS layer distribution [71]

The snaps are sent to the app store, where they become available for download on the IoT device. The apps are updated automatically in the background, and it is easy to roll back to a previous version in case of errors.

• Fedora Atomic [109] is a project between Fedora and Project Atomic that creates software frameworks with Fedora and Project Atomic for cloud servers.

• CoreOS [103] is an open-source lightweight Linux-based OS designed around containerisation and mainly for cloud based hosts and also supports a high number of physical machines. It has no package manager, assuming that all the applications run in containers. Container cluster management is done with Kubernetes. Dual- partition OS updates are also supported. It supports a wide range of x86-64, but it does not have support for ARM devices.

• BalenaOS [71] is an open-source operating system built around containerisation for IoT embedded devices. The core OS is built with Yocto and has the minimum set of components for stable operation. The applications are deployed in a Docker container for ease of portability and full image updates. The main OS builds can be made via Yocto Jethro, which is not supported anymore due to the release of two other more recent versions.

Unikernels [92] are specialised, single address space machine images build using operating system libraries. They run directly on hardware or hypervisor without the intervention of any OS. They have small sizes and are application-speciﬁc built, with minimal libraries and dependencies. They are ideal for constrained environments speciﬁc to Internet of Things devices. Some operating systems libraries that can be used for constructing unikernels are MirageOS, HaLVM, and Rumprun. 22 Chapter 2 The Internet of Things in our lives

• MirageOS [92] is an operating system library for unikernels written in OCaml programming language and includes libraries to support networking, concurrency support and storage. It is fully event-driven, with no support for preemptive threading.

• HaLVM (Haskell Lightweight Virtual Machine) [155] is a library that enables writing programs that run directly on the Xen hypervisor. It is written in the Haskell programming language and can use non-Haskell libraries using the standard Haskell Cabal toolset. It allows for very lightweight, single-purpose Xen domains with minimal resource requirements to be run directly on the hardware and can be used for IoT devices.

• Rumprun [92] is built on a foundation of rump kernels, uses rump kernel drivers, has a libc and an application environment on top and provides a toolchain to write Rumprun unikernel applications. It can support existing application-level software without the need to port it, maintaining the unikernel small memory footprint advantage.

2.3.5 Over the air updates

Billions of IoT devices are going to be deployed across the world in the next years. These devices are going to be part of smart homes, smart cities, and will monitor the environment [62]. Managing all these IoT devices is a challenge, physically intervening to update and troubleshoot them will be nearly impossible. Researchers are working towards developing stable, reliable systems for remotely managing IoT devices. Over the air updates are a signiﬁcant part of this work, and this subsection exempliﬁes some of the most reliable OTA strategies.

There are three main types of OTA strategies:

• Full image updates - the standard update for Linux embedded systems. There are two types of such updates:

– Single image approach - assumes that the new image will boot, and has the possibility of recovering if the update can be performed from fallback factory bootloader. – Dual image approach - gives the possibility of rolling back to the previous working image in case of failure

• Incremental image updates minimises the size of the updates sending only changes composed of binary deltas for the modiﬁed ﬁles. It provides incremental atomic upgrades that can be easily deployed or rolled back and a complete history of deployments. Chapter 2 The Internet of Things in our lives 23

• Containers - built on top of an immutable core distribution, where the upgrades are deployed in containers. This cannot be used as a complete upgrade solution. Currently, there is a lack of tools providing this type of update.

The following software tools are built using these strategies:

• Mender [99] is an open-source remote updater for embedded devices. It is based on a dual image update framework. It has two client modes: standalone, where the updates are triggered locally and managed, where the client is a daemon and polls a server for updates. It uses the notion of commit when the updated has booted properly, and it toggles the inactive/active partitions in case of failure, which represents the fail-safe mechanism. It also contains an extra partition for data persistence, which remains unchanged during the update. The meta-mender layer can be used to build the client into a Linux OS distribution using the Yocto project.

• Swupdate [139] is a software update strategy for embedded systems. The updates can be made locally or over the air. It uses single image updates; hence it does not provide a rollback option in case of failure.

• swupd was initially part of the ClearLinux [18] project, and it is based on an incremental atomic upgrade mechanism. The updates are created and handled by a swupd-server and delivered as streams of bundles containing binary deltas to the swupd-client. The system does not require a boot after the update was made, and the meta-swupd layer allows building the mechanism into clients using the Yocto project.

• OSTree [150] mechanism is very similar to swupd, with the exception that it does need a reboot after the update has been installed. OSTree is a popular tool, used for projects such as Project Atomic, Fedora Atomic, Qt for Device Creation. The deployment process follows the steps below:

– an updated image tarball is committed on the OSTree repository – an update/upgrade is triggered on the host side – a system restart is triggered on the host side for the new ﬁlesystem-set to take eﬀect

Cockpit [109] is a software tool that provides administration and visualization for hosts and container clusters and can be integrated with OSTree.

• Balena.io [21] oﬀers an OTA update system for containers. The client-side of the system is open-source, but the server-side is proprietary. This would be a useful OTA for the project presented in this work, but we chose not to use it due to its proprietary nature. 24 Chapter 2 The Internet of Things in our lives

APP 1 APP 2 APP 3 APP 4

BINS/LIBS BINS/LIBS BINS/LIBS BINS/LIBS

CONTAINER ENGINE

HOST OS

Figure 2.3: Figure showing the containerisation architecture and the relationship between container applications and the host OS

2.3.6 Containerisation

Containerisation is a technique of deploying software programs in an encapsulated environment that contains its own OS, the application and its dependencies, and has limited access to the underlying software system. The host OS and the container OS share the same kernel.

Containerisation can be easily confused with sandboxing. Sandboxing is a technique of isolating running software programs from the underlying software layer, providing a limited set of resources and read/write capabilities for the guest software. Sandboxing is usually used to run untrusted programs, i.e., in Windows. Containerisation limits the set of resources available to the guest software, as well as allowing the deployment of a new opperating system and dependencies in an encapsulated environment. As an example, web browsers run websites’ javascript code in a sandboxed environment restricting access to resources and ﬁles on the host computer, but it does not deploy it in a container.

Containerisation and sandboxing are used for IoT applications because of the ﬂexibil- ity and increased security they oﬀer around building, testing, running, and managing applications.

Containerisation is particularly useful for IoT devices as it increases reliability, speeds applications deployment, and migration, minimises the size of the OS and beneﬁts applications and hardware upgrading. This section exempliﬁes some of the most popular containerisation software tools.

• Docker [100] containers share the same kernel with the host OS. They can run on Linux distributions and Microsoft Windows. Chapter 2 The Internet of Things in our lives 25

APP 1 APP 2 APP 3 APP 4

Sandbox Sandbox

HOST OS

Figure 2.4: Figure showing the sandboxing software architecture and how sandboxed applications are isolated from the other applications

• Docker Engine is part of Docker, and it is the tool that helps building and running containers.

• Docker Hub is also part of Docker - a SaaS service for application sharing and managing.

• Docker Machine [144] is a tool that can be used for provisioning Mac or Windows with Docker or for installing and managing remote Docker hosts.

• Docker Swarm [144] helps manage Docker Engines at scale using an API. It helps to deploy clusters of Docker Engine hosts. The clusters act as a single computer, and the tasks are deployed per swarm only, and cannot be assigned individually per node in the swarm.

• Kubernetes [28] is a management tool for container clusters. Kubernetes oﬀers means of networking, scheduling, load distribution, and data persistence for container- based architectures. It addresses containers using labels. The containers can be organised in pods, which can contain any number of containers, but generally, they contain one or two containers. It also has a replication controller and AK8S service that is persistent, provides discovery, load balances VIP layers, and identify pads by label sector. Volumes can be mounted as ﬁlesystems, and it also has a grouping mechanism, called namespacing.

• Singularity [91] containers can run an OS independent of the main OS. The container user privileges are shared between the container OS and the host, i.e., root access in the container is given to users that have root access on the host OS. This helps to preserve privacy and provide security.

• rkt [123] is an open-source command-line interface for running application containers on Linux with varying degrees of protection. The primary interface is a single executable that makes integration with existing containerisation tools easier. It 26 Chapter 2 The Internet of Things in our lives

implements the App Container (appc) container format, and it can also execute containers in other formats, such as Docker containers.

2.4 Internet of Things applications

2.4.1 Air Quality monitoring

Array of Things

Array of Things (AoT) [36] is a project that uses a network of modular sensor boxes for urban sensing. At the time of writing (September 2019), there are 127 sensors deployed within the city of Chicago but the project is running in a few cities around the world. The sensors are measuring data on air quality, climate, traﬃc, and other urban features and are described as “ﬁtness trackers” for the city. The data produced by the sensors is available as open data through the AoT platform.

The boxes are built using the Waggle platform [22], which has a modular architecture and supports by default sensors that measure: barometric pressure temperature, ambient light, acceleration, vibration, remote surface temperature, sound level, magnetometers. Besides these, the AoT boxes also include air quality sensors that measure Carbon Monoxide, Nitrogen Dioxide, Sulphur Dioxide, and Ozone. Further work will look into monitoring other urban factors of interest, such as ﬂooding and standing water, precipi- tation, wind, and pollutants.

OpenSense

OpenSense[5] is a partnership between the National Air Pollution Monitoring Network in Switzerland and other parties in developing, deploying, and researching mobile air quality monitors. Up to date, they have developed a prototype of an air quality monitoring device that measures Ozone, Carbon Monoxide, Nitrogen Dioxide, and ultra-ﬁne particles. The sensors have been deployed on ten trams in Zurich, and they collect data when the tram is stationary to mitigate the eﬀects of tram movement on the data. A sensor has also been deployed at Switzerland National Air Pollution Monitoring Network. The sensor data can be accessed online over their Global Sensor Network (GSN) [4].

Stuttgart, Germany

The Open Knowledge Lab [141] in Stuttgart, Germany have developed a PM monitoring device for a citizen science project. The project uses the NodeMCU ESP8266 microcontroller, two pipes, DHT22 temperature, and humidity sensor and SDS011 ﬁne dust sensor. The project has been crowdfunded, and anyone interested in mounting one of the sensors at their home can go to one of the public assembly workshops hosted by the Open Knowledge Lab and build their own sensor. Chapter 2 The Internet of Things in our lives 27

AirPi

AirPi [8] is a sensors kit built using Raspberry Pi. The kit contains sensors for monitoring weather conditions such as temperature, humidity, and UV levels. It also contains air quality monitoring sensors such as carbon monoxide, nitrogen dioxide, and smoke level. The sensor device records the data and logs it via the internet. The project is open- source, the kit can be bought for $ 90, but it can also be built from scratch as all the information needed is available online. The sensors used for air quality monitoring have the advantage of being low-cost but are not sensitive enough to provide reliable readings. Their sensitivity range is lower than the maximum safest amount of some of these gases in the air.

Home automation hubs

Very popular at the moment are home automation hubs. These devices are built for controlling different home IoT devices, such as smart thermostats, lighting, smart TV, and others. Google Home [110], Amazon Echo [119] and Wink Hub 2 [98] are just a few examples of these devices. Although the idea of being able to control all the home appliances with a single device has multiple benefits, such as price and extending the capabilities of home appliances, they are also greatly affected by interoperability limits being able to manage a defined number of devices. They also raise concerns regarding the privacy of the users and security.

2.4.2 Plug and Play platforms

Libelium [88] has developed multiple plug and play sensor boxes to be used for diﬀerent applications like environmental monitoring and agriculture. These devices run on a custom-built microcontroller, Waspmote, which uses ATmega1281. It has a frequency of 8 MHz, 8KB SRAM, 4KB EEPROM, 128KB FLASH, 2GB SD card, seven analog inputs, eight digital input/output pins, 2 UARTs, 1 PWM, 1 I2C bus and 1 USB port.

The main disadvantage of the Libellium hardware is that, despite having plug and play features, each development platform has a speciﬁc range of sensors it can work with, which have to be bought from the Libellium company. Additionally, Waspmote is built- in, and it is the only processing board that can be used for their platforms. Although this decreases the complexity of the deployment, it also limits the use cases and makes it not suitable for research or ongoing development of smart cities. Furthermore, the cost of the Libellium products makes them unaccessible to small research teams, and they are targeted for entreprise use.

The Waspmote runs a dedicated program. It also has a system manager - Meshlium - which is a hardware Access Point that can also be used to run the system management server. The management server can be used for updating the applications (sketches) 28 Chapter 2 The Internet of Things in our lives

OTA, networking, and monitoring the system. These characteristics are in line with the architecture proposed in this thesis. Although they are independent of each other and hence provide a level of modularity, they are unique to the Libellium ecosystem, and other tools are not available to use. Hence, their system limits the range of applications it can cover.

The Libellium devices have been used for mobile air pollution monitoring using buses [26] and for ambient and environmental conditions monitoring in the city centre in Ljubljana [86]. They have also been deployed in the Hampshire county for monitoring weather conditions and road temperature for optimising the amount of salt that is spread on the roads during the winter [87].

The BeagleBone Green is a low-cost, community-supported, open-source development platform, fully compatible with BeagleBone Black featuring AM335x 1GHz ARM Cortex- A8 with 512MB DDR3 RAM, 4GB 8-bit eMMC onboard ﬂash storage. It also has two Groove connectors (SPI and I2C) and two 46 pin headers. This makes it a great development platform that can be used in the hobbyist and academic communities, but it cannot be easily used in production, as it would need further adjustments. It does, however, represent an excellent technology to be used with the hardware development HAT [12] presented in this work.

At the software level, the BeagleBone Green does not come with a pre-deﬁned software stack, it is not dependent on any proprietary architecture, and it can run a wide range of OSs.

Zolertia [64] produces a series of commodity hardware platforms that allow fast development for IoT devices. The Zoul is a core module based on TI’s CC2538 system on chip (SoC), it has an ARM Cortex-M3 with 512KB Flash and 32KB RAM, that can fit a wide range of prototyping boards. They also produce RE-Mote, a hardware development platform that includes, among others, two radios, external SD card storage, low-power operations, Real-Time Clock, and has available interfaces and connectors for plugging in different sensors. Another one of their products, Firefly, is a hardware development platform built on top of the Zoul module that has ultra-low power consumption and has most of the pins exposed for ease of development. It is compatible with breadboards and battery holders. Its main disadvantage is the limited processing power, given by the Zoul module, which in turn limits the range of applications it can cover.

BalenaOS [71] is an open-source OS built around containerisation for IoT embedded devices and part of the balena.io project. The core OS is built with Yocto and has the minimum set of components for stable operation. The applications are deployed in Docker containers for ease of portability, and full OTA image updates are also possible, using resinhup, a Docker-based tool developed by balena.io for full OS updates. However, although the OS is built using the open-source Yocto project, adding new capabilities or making modifications to it is highly difficult and time-consuming. It introduces low-level Chapter 2 The Internet of Things in our lives 29 specific modifications that are not compatible with other layers than the ones used in the Balena project. For example, in the project presented in this work, it was tried to integrate delta OTA updates and balenaOS, but failed due to the distribution incompatibilities between the layers introducing the balenaOS and OTA capabilities respectively. Furthermore, the project seems to be using old versions of the reference distribution, poky, of the Yocto project, always being a few branches behind the latest stable one. This introduces problems such as outdated software versions that cannot be used with present relevant developments.

The Project Atomic [109] is an initiative that supports re-designing the OS around containerisation. It comprises of a lightweight container OS, the Atomic Host, where the applications run in containers. The host has Kubernetes [65] installed by default, uses Docker [25] and is managed with rpm-ostree. The project also has diﬀerent tools available such as AtomicApp for developing contained applications, Atomic Registry for registering the containers, and Cockpit to give visibility into the host and containers. It has been developed for server management and development and does not have support for embedded systems. Fedora Atomic [109] is a project between Fedora and Project Atomic that creates software frameworks with Fedora and Project Atomic for cloud servers.

Project Ara [158] was a Google project with the aim of developing a modular smartphone that could accomodate hardware and software updates, aiming to increase device lifespan and minimisation of e-waste. The proposed smartphone consisted of a frame and modules - such as cameras, speakers, WiFi - which could be updated over time. The project was based on Modu [106], a lightweight modular cell phone which allowed users to add keyboard, sporty chassis, camera, and MP3 player and which was bought by Google in 2011. At the bases of the Ara smartphone was a propietary frame, which could integrate Google-approved modules. In 2016 the project ended for unclear reasons. Modular consumer devices are becoming decreasingly common, with popular companies, such as Apple, providing high-performance un-upgradable devices.

In conclusion, although there are diﬀerent development platforms for IoT devices, these impose limitations, such as limited processing power or a limited range of sensors they can cover. The available software even further increases these limitations. IoT devices are deﬁned by both hardware and software.

2.5 Research Questions and Objectives

The literature review identifies the need for new IoT architectures where technology can be integrated after deployment in order to allow upgrading, maintenance, and re-use of existing infrastructures for new application deployment. Some research projects and companies have already made the initial progress in the area, but their solutions are 30 Chapter 2 The Internet of Things in our lives limited to hardware or software-only or built for specific use cases or can be used within vendor-specific ecosystems only. The main questions we are answering in this research are:

• Given the continuous evolution of IoT technologies, what are the requirements that need to be met by the IoT devices in order to make them adaptable to new applications and technologies?

1. What hardware design requirements need to be met in order to build devices that are able to change their functionality after deployment and adapt to continuous technological development? 2. What software design requirements need to be met in order to build devices that are able to change their functionality after deployment and adapt to continuous technological development?

To address these questions, we establish the following objectives for this thesis:

• To develop a generic IoT hardware platform that can be used with oﬀ-the-shelf sensors for smart city distributed sensor networks. Chapters3 and4 explore the requirements for the generic device.

• To implement this platform such that it can use a wide range of sensors, independent of manufacturer, interface, and other similar barriers often met with IoT devices. Chapter5 presents a genric hardware development board that meets the design requirements, with an implementation of the device as an environmental monitoring use case.

• To be able to swap sensors during operation, allowing to update the device speciﬁca- tions and to add new capabilities and applications, as required. Chapter5 presents the hardware implementation and validation of the generic device presented in this work.

• To explore potential sensors for a ﬁrst use case and implement it. Chapters3 and 4 explore potential sensors to be used for an use case, while5 presents an environmental monitoring device, which serves as an use case of the solution presented in this work.

• To identify software requirements for this type of generic device and create a software architecture. These requirements are explored and detailed in Chapters3 and 4.

• To explore existing software packages and tools that will enable or speed up the implementation of such an architecture. Chapter6 detailes the software packages and tools considered for the implementation of the software architecture. Chapter 2 The Internet of Things in our lives 31

• To develop a reference implementation of the architecture that can serve as a working example and a starting point for new projects. A reference implementation is presented in Chapter6.

In the following chapters, we are focused on answering the research questions by following these objectives.

Chapter 3

Indoor positioning system

The main role of this chapter is to identify the requirements for an IoT system deployed at diﬀerent scales and how continuous technological evolution is inﬂuencing the IoT networks in order to answer this work’s research question.

This chapter is organised into three sections. The first section presents an indoor positioning sensors network, and it is based on the Indoor localisation system based on low-cost commodity hardware paper that was presented at the UbiComp16 conference [13]. The second section presents the same technology but deployed at a larger scale and in two different environments, an office area and outdoors. The third section brings to light the issues that were faced when managing multiple IoT devices, how technological evolution is impacting the presented network, and identifies requirements for designing, deploying, and building the next generation IoT device that would solve some of the issues identified through this experiment.

33 34 Chapter 3 Indoor positioning system

3.1 Indoor localisation system based on low-cost commodity hardware

Pervasive indoor positioning is a key enabler for ubiquitous computing. Although a number of indoor positioning systems exist, we identify that there still is a barrier between these and the consumer. There is a need for a cost-eﬀective, practical solution that can be easily designed, built, tested, and deployed.

We have built a low-cost indoor positioning system with oﬀ-the-shelf commodity hardware to provide an example of an accessible ubiquitous platform for developers, academia, private individuals, big and small companies, and institutions. The system is low-power, modular, performs auto-calibration, can track any WiFi-enabled device, and can be used for other applications alongside indoor positioning.

3.1.1 Introduction

A practical, cost-effective indoor positioning system (IPS) is one of the key enablers of ubiquitous computing. Although a large number of such systems [89] have emerged since Weiser defined ubiquitous computing [153], we believe that there still exists a barrier between these and the consumer. For example, the industry does not focus on developing ubiquitous solutions, and some commercial products [24, 152,7] do not provide services for small spaces, aiming at large areas such as airports, universities, hospitals, and large retail companies. Furthermore, their products are often expensive, and the tracked asset requires specific localisation hardware such as smart tags. Table 3.1 details the costs and performance of some of the leading systems. High accuracy algorithms and systems have been developed in academia, but they are often not ubiquitous and require specialised knowledge [146, 94]. Fingerprinting-based indoor positioning is a popular choice, but collecting fingerprints requires user interaction, is impractical, and imposes a barrier on the user. There is a need for a low-cost, practical IPS that can be easily deployed. Weiser claims that in ubiquitous computing, we can only learn by experimenting. Hence, we need a simple system that allows for further experimentation with location-aware applications, but also with WiFi-based indoor positioning algorithms.

We present a low-cost WiFi-based IPS that uses Raspberry Pi devices for collecting and processing data. The system is ubiquitous, it collects the data without user input, and the remaining Central Processing Unit (CPU) capacity can be used for other applications, representing a valuable development platform for ubiquitous applications. It performs auto-calibration: for each node, all the other nodes of the system act as anchors, allowing for wall alleviation factor to be calculated. Each node can be battery powered and has a modular conﬁguration, allowing for swapping and adding sensors. The system can track any WiFi-enabled device, and it works with Linux-based Operating Systems (OS). Chapter 3 Indoor positioning system 35

Table 3.1: Cost and accuracy of indoor positioning systems that are currently on the market (2017) and have their pricing available. Please, note that the prices are subject to change, and the accuracy of the systems depends on the density of locator nodes per m2.

Product LN Accuracy Services Installation Tag Licence Support Accuware $ 30 - 40 2 - 4 m $195 1 $ 60000 $ 59 $ 99 2 $ 75000 3 Indoors $ 30 - 40 4 2 - 5 m $ 499 - 999 5 ad-hoc N/A $ 95 - 990 6 infsoft $ 170 2 - 5 m N/A $ 1000 N/A 5500 ad-hoc Air-Go $ 230 up to 2 m $ 163 7 8 $ 51 N/A ad-hoc 1 monthly subscription to the cloud server - up to 50 tracked devices 2 per device running Accuware software 3 per year 4 approximate price of an access point 5 per month 6 per month 7 per year 8 ad-hoc - approx. 15% of the total project cost

Figure 3.1: Locator node

Model Price RPi 2 Model B $ 35 WiFi RALINK3070 $ 17 WiFi EW 7811UN $ 10 Power Supply T6143DV $ 7 SD card SanDisk Ultra 64 GB $ 12.5

Table 3.2: Details of the components of the locator nodes used for this study including prices and models. The prices are valid at the time of writing (2017) and they might change in time.

3.1.2 Design of the Indoor Localisation System

The system has two components: locator nodes that collect data from WiFi-enabled devices and a server that runs on one of the nodes. Figure 3.1 shows one of the locator nodes and Table 3.2 details the hardware components of each locator node. The two WiFi cards are used for monitoring the tracked devices and for connecting to the local network respectively. 36 Chapter 3 Indoor positioning system

The tests presented in this work have been performed using Raspbian OS. OpenWrt, which is an OS speciﬁcally designed to deploy on Access Points and routers [51], has also been successfully tested.

The Free Space Path Loss theory [120] and the trilateration algorithm [93] have been used to compute locations of the tracked devices. The ﬁnal location estimate is assumed to be the centre of the smallest circle that can be formed using the best k solutions yielded by the trilateration algorithm.

The best k solutions are ﬁltered based on the Euclidean distance between them and the locator node with the highest signal strength. k, and the number of locator nodes were chosen to be two based on iterations made on multiple data sets.

Each locator node collects data (the Media Access Control address, received signal strength) on channel 11 using the Python library scapy and sends it to a HTTP server, that computes the coordinates of the active WiFi devices and displays them on a web page in real-time. The data from the locator nodes is sent continuously to the server and saved in log ﬁles, but not used for coordinate computations if it has been in the system for more than one minute.

Besides tracked devices, the locator nodes are also monitoring each other. Knowing the real location and the signal strength variation at each locator node allows for the wall alleviation factor to be calculated, where wall alleviation factor represents the variation in signal strength due to LOS obstacles in the environment. This enables the system to adapt to changes in the environment.

3.1.3 Preliminary Testing

3.1.3.1 Methods

The tests have been conducted in a busy office area of 30x13 m2. The office, shown in Figure 3.2, contains computers, tall metal drawers, thick pillars, four Access Points, printers, microwaves, Bluetooth enabled devices, and other furniture and equipment typical in an office environment. Figure 3.3 shows a 2D top view representation of the testing area and the positions of test points.

The measurements have been taken using a Fluke 414D laser distance meter that has an accuracy of ± 2 mm, and the tracked object was a Kazam Thunder 45L smartphone.

The tracked device was held stationary at each of the test points. The results represent the average of all the coordinate estimates obtained at each of the test points.

The error has been calculated as the Euclidian distance between the coordinates yielded by the positioning system and the physical location of the tracked device. Chapter 3 Indoor positioning system 37

Figure 3.2: Image of a section of the oﬃce area illustrating the testing environment

Figure 3.3: The testing area layout showing the position of the locator nodes (Pi) and the locations where data is collected. The test points are numbered in an ascending order from left to right hand side along the width of the test environment.

3.1.3.2 Results

Tests were taken using five locator nodes, and the results are illustrated in Figure 3.4. It is noticed that the accuracy decreases from the left to the right-hand side of the testing area. The results are influenced by the positioning of the locator nodes relative to the measurement points and to each other, and by interference and Line-of-sight (LOS) obstructions. To prove this theory, we re-calculated the tracked device coordinates in the test section, where the nodes are evenly spread, and less LOS obstructions and interference are present. We chose to use three locator nodes only (one, three, and four) to re-calculate the coordinates at the first nine test points. The results show a decreased locating accuracy, as illustrated in Figure 3.5, supporting our theory. Furthermore, comparing these results with the ones that were obtained previously at the same points, 38 Chapter 3 Indoor positioning system

Figure 3.4: Graph illustrating the error variation at 17 measurement points. The accuracy of the system is ±3.09 m with a standard deviation of 1.24 m

Figure 3.5: The error variation at the ﬁrst nine measurement points when three locator nodes have been considered: Pis 1, 3, 4. The accuracy of the system is ±2.59 m with a standard deviation of 1.44 m.

it is noticed that better accuracy is obtained when more locator nodes are used. It demonstrates the impact of the number of locator nodes on the accuracy of the system.

In conclusion, the results presented in this section suggest that better accuracies could be obtained by increasing the number of locator nodes and minimising the line of sight obstructions within the testing area. In order to confirm these findings, more experiments are designed, where the number of locator nodes is increased. The experiments are conducted in two different environments, to clarify the impact of LOS obstructions on the accuracy of the system.

3.2 Further assessment of the system performance

The work presented in the previous section describes a low-cost IPS system that can be used as a development platform for location-aware applications. Preliminary tests demonstrated 2 - 3 m average accuracies. Chapter 3 Indoor positioning system 39

This section presents how the device performs in two diﬀerent environments under more in-depth tests.

3.2.1 Methods

To further assess the performance of the system, we developed an experiment that used six locator nodes to track ten devices simultaneously. The locator nodes and tracked devices were attached on top of 1.5 m poles. The locator nodes were positioned such that they represented triangles vertices for better node distribution across the assessed area. The tracked devices were ten Raspberry Pi 3 model B. Each of the tracked devices was stationary during the measurements, and we took measurements for ﬁve minutes at each of the test points. The ten tracked devices were moved across the testing area in eight conﬁgurations, which yielded approximately 80 data points.

The server was located on a Raspberry Pi, which was also an Access Point to which the locator nodes were connected to transmit data without an Internet connection. The tracked devices were connected to another Access Point, the EE 4GEE WiFi. The Raspberry Pi devices used for the locator nodes were also replaced with the Generation 3 model B ones, which reduced the cost of the system by $10. All the other methods remained unchanged from the previous tests described here.

The system was tested in two different environments: in the office area described previously and outdoors (Southampton Common) in clear line of sight conditions. The test area and positions of the locator nodes and the tracked devices relative to each other were kept the same in both tests, and the only change is that the second environment does not have any office furniture and equipment, and there are fewer radio devices producing interference. The system was tested in the second environment to assess the influence of LOS obstructions and interference on the overall performance of the system.

3.2.2 Discussion and analysis of the results

Preliminary data processing gives an accuracy of 6.58 m for the tests conducted in the office area and 9.5 m for the tests conducted in the park. The error variation with respect to both x and y is illustrated in Figure 3.6 for the office tests and Figure 3.7 for the park tests. These results are different from what we have obtained before - the error is greater.

The best solutions are filtered based on the difference between the Euclidean distance between them and the locator nodes and the distance calculated using Free Space Path Loss formula. In order to check if this approach is correct, we re-calculated the coordinates of the tracked devices filtering the best solutions using the distance between the real coordinates and the coordinates yielded by the trilateration algorithm. The average error obtained in this case is 2.86 m for the tests conducted in the office area, displayed 40 Chapter 3 Indoor positioning system

Figure 3.6: Variation of the position estimation errors at the measurement points for the indoors experiment.

Figure 3.7: Variation of the position estimation errors at the measurement points for the outdoors experiment. Chapter 3 Indoor positioning system 41

Figure 3.8: Variation of the position estimation errors at the measurement points if the method of choosing the best solution would be ideal. This is the data for the indoor measurements. in figure 3.8, and 3 m for the tests conducted in the park, shown in figure 3.9, This means that improving the way we choose the final coordinates of the tracked devices could improve the accuracy of the system.

Figures 3.6 and 3.7 also show that for each point, we have found more than one result. This is explained by the fact that we took multiple measurements at each of the points.

Being able to ﬁnd a way to automatically choose the best result at each of the points in real-time would reduce the system error. One way of doing so is by deﬁning a scoring method for the solutions and applying an upper bound that, if exceeded, the solution is discarded. This is the approach we chose when processing this data.

The scoring mechanism creates a score for each of the solutions yielded by the trilateration algorithm per reading. The score is the squared diﬀerence between the distance used in the trilateration algorithm and the distance between the solution considered and the locator nodes multiplied by the signal strength. This way, the strongest signal will yield a small score. The solution with the smallest score is considered the best.

Another approach was to minimise the signal noise by comparing the signals between two locator nodes, i.e., the signal between locator nodes 1 and 2, as seen at locator node 1 compared with what is seen at locator node 2. Doing this for all the combinations of locator nodes, we are able to minimise the overall system error by approximately 1 m. 42 Chapter 3 Indoor positioning system

Figure 3.9: Variation of the position estimation errors at the measurement points if the method of choosing the best solution would be ideal. This is the data from the outdoor measurements.

Finding the optimum coordinates for the tracked devices by minimising the mean square error, the score described above didn’t improve the results for the system. The values obtained using this method were 6.87 m for the oﬃce measurements and for 9.66 m for the park measurements.

Python (using scikit-learn) machine learning (ML) algorithms, neural networks, and lin- ear regression have been used in the effort of finding a scoring algorithm that would yield the best solution given by the trilateration algorithm per reading. However, the algorithms failed to find any correlation between the best solutions and signal strengths. Using ML for replacing the trilateration algorithm was not successful either. The algorithms have been trained with data varying from 20% to 60% of the data. Data augmentation has also been used for training purposes in the effort of eliminating the need for calibration prior to the deployment, which is the aim of this work. Using the models created in this way reduced the solutions pool to only two: the origin and the middle of the test area, for any number of data points. This helped us understand that the noise level is high, and finding a correlation between the signal strength and device location is difficult. Further developing the algorithms could lead to better results, but it was decided that ML might not be the best approach to solving the given problem.

The received signal strengths at each locator node are subject to unknown levels of noise. If we calculate the estimated distance di between locator node i and the device we’re Chapter 3 Indoor positioning system 43

2Δ

Figure 3.10: This image illustrates how the solutions interval can be considered as the intersection between the rings created as a result of combining the signal strength and the parameter ∆; where ∆ represents the signal noise. trying to locate using the Free Space Path Loss formula and draw a circle of radius d for each locator node, we will notice the circles do not necessarily have a common intersection point. We can overcome the noise by adding a parameter ∆, as described by [133]. Then for each locator node, instead of using a circle with radius di we use the area between two circles of radius di +∆ and di −∆, as shown in ﬁgure 3.10. We call this area the ring ri. The middle point of intersection between all ring areas ri for i = 1, 6 is the estimation of the location of the tracked device. For quick experimentation, this method was implemented using the OpenCV library by simply drawing each ring black with 0.3 opacity and thresholding the image for the darkest colour to obtain the intersection area. The centre of that area is the prediction point. Rendering the image size is such that 1 centimetre = 1 pixel. Using this approach, we get accuracies of 8.23 m for the indoors experiment and 9.05 m for the outdoors one.

Using diﬀerent methods does not increase the accuracy of the system from 6.87 m for the 44 Chapter 3 Indoor positioning system

Figure 3.11: Radiation pattern of the omnidirectional, high-gain antenna used for this project [143] indoor measurements and 9.05 m for the outdoor measurement. The system performed the worst in the park experiment. This means that the interference is introducing sig- niﬁcant noise in the data readings. By adding more WiFi devices that send data using the same channel, more interference is created (co-channel interference), which is why the preliminary testing yielded better results. Devices spacing and density also have a signiﬁcant impact on the data.

The antenna used for the testing is 5dBi gain omnidirectional antenna, and its radiation pattern is described in ﬁgure 3.11. As both the tracked devices and the locator nodes were placed on 1.5 m poles, we are only interested in how the antenna behaves in the horizontal plane. Looking at the respective radiation pattern, we can see that the radio signal is radiated equally in all directions.

Furthermore, changing the Access Point from Eduroam (provided by our University IT department) to a mobile one, as compared with the preliminary experiment presented in the first section, might also have caused the difference in the results. Different networks have different forms of interference mitigation.

Even if outdoors, there were fewer obstructions, the ground, the poles, the devices themselves, and the people walking around in the area are forms of obstruction and introduced noise in the data. It is also possible that some of the locations of the tracked devices were not measured correctly, some of the devices were mislabelled, and others fell during the measurements.

Attenuation, refraction, reflexion, and diffraction are altering the signal received at the locator nodes, introducing a high error that is very difficult to mathematically model. Signals are minimised, increased, and attenuated when they come in contact with each other and the environment. General patterns are very hard to find with such a system Chapter 3 Indoor positioning system 45 that is highly unpredictable, considering all the processes that the radio waves are undergoing. Systems that perform calibration before deployment can give good accuracies because they can create a model of the environment. Being able to change the hardware can also increase the accuracy of the system. However, trying to get a precise indoor positioning system without any of these is highly complicated and has not been achieved up to date.

There are ways of increasing the accuracy of the system, for example, knowing if the tracked device is stationary or not could help us filter the data at each point more accurately. Accurate timing could also lead to improved accuracy. Using other algorithms for data filtering and using different localization techniques than trilateration might also lead to increase accuracy.

3.3 Conclusions and future work

The system helped us understand how WiFi-based positioning using oﬀ the shelf hardware can be used. This study shows 6.87 m accuracy for the indoor measurements and 9.05 m accuracy for the outdoor measurement. Using more hardware than WiFi dongles to track devices in a less radio-dense environment could yield better accuracies. Depend- ing on the application and the environment, the system could be used to determine the number of devices in the room and even their general distribution, although obtaining precise coordinates is challenging.

Looking deeper into radio propagation and its characteristics could also lead to a better understanding of the system and how to improve it. However, this is not the purpose of this work, and although the accuracy of the system could be improved by employing different technologies, we have not identified a clear path towards significantly improving the system within the constraints of only WiFi and without fingerprinting the target environment.

During the research undergone in this chapter, multiple systems using more sensors or other technologies have emerged, which rendered better accuracies. After undergoing an in-depth literature review, it has been noticed that, given the accelerated rate at which the technology is evolving in this area, most of the devices built for smart applications have a relatively short life, where most of them are disposed of in favour of better versions. Hence, deploying smart devices at a large scale can be wasteful, while the complexity of building on top of existing systems increases exponentially.

The experiment presented in this chapter can be improved by using an entirely different set of sensors [14]. Every year, new research studies in indoor positioning introduce systems with improved accuracies, which use different sensors and mathematical mod- elling techniques. Hence, a durable indoor positioning system deployed at a large scale 46 Chapter 3 Indoor positioning system requires incorporating these new technologies after deployment in order to efficiently integrate with new advances in the IoT area for the generation of better services and applications. This aspect, customisation, needs to be met by new IoT architectures. In this work, a customisable architecture allows updating to new technologies after deployment, for example, sensors, actuators, and applications, with no vendor-specific restrictions.

Adding new sensors and actuators to the existing devices deployed in this work could also lead to better accuracies [49]. Adding new sensors to the deployed devices could also enable new applications to be deployed without the need for building new infrastructure. The ability to expand devices after deployment is also a requirement that needs to be implemented for new IoT architectures to increase life span and decrease the complexity of deploying new smart applications. In this work, extensible refers to the property of architectures to integrate new technologies after deployment, such that new applications can be added to already existing infrastructures to enable the creation of a circular economy for sustainable city development.

Replacing sensors and adding new ones needs to be enabled not only from hardware but also from the software level. For example, in the experiment presented in this chapter, data processing has been done using diﬀerent methods. If the data processing would have been done on the edge, all of these applications had to be deployed on the devices during operation. New technological advances in hardware drive new software developments. Hence the next generation IoT devices architecture needs to meet the design requirements at both hardware and software levels to enable increased life span and minimise device management complexities.

In order to increase the life span of IoT devices, new methods of maintaining them that save time and costs need to be developed. Maintainable refers to the property of an IoT system architecture to enable device upgrades and repairs via modularity in order to increase life span. The next generation IoT device also needs to be accesible, and not rely on vendor-speciﬁc ecosystems or require extensive training in order to be able to use it.

The remaining of this thesis is exploring potential designs for meeting the design requirements identiﬁed in this chapter: accesibility, customisability, extensibility, and maintainability. Chapter 3 Indoor positioning system 47

Requirement Definition Accesibility An accessible architecture can be used and maintained by the general user and does not require a high level of training. It should also not be restricted by vendor specific ecosystems or cost. Customisability A customisable architecture allows updating to new technologies after deployment, for example, sensors, actuators, and applications, with no vendor-specific restrictions. This allows increasing the device life-span and reduces e-waste. Extensibility The property of IoT architectures that allows using already deployed infrastructures for new applications, allowing the creation of a circular economy for sustainable city development, while reducing the complexity of deploying new technologies and reducing the e-waste. Maintainability The property of an IoT system architecture to enable device upgrades and repairs via modularity in order to increase life span and reduce e-waste.

Table 3.3: Modular device architecture requirements and deﬁnitions

Chapter 4

Generic IoT device for an environmental monitoring use case

This chapter explores the potential of meeting the design requirements identiﬁed in the previous chapter -availability, customisability, extensibility and maintainability - using a generic IoT device which includes a wide range of sensors to support new applications after deployment. Air quality is an important global concern, and it has been used as a use case for this chapter.

Southampton is the 5th most polluted city in the UK. London has been regularly ex- ceeding the yearly European pollution limit in the first calendaristic months of each year [124]. In order to address these issues, there a need for high granularity data across cities. The city council is providing a few high-quality base stations for monitoring the air quality, i.e., 3 in Southampton, but these are not enough in order to find the main causes of the pollution and find mitigation methods. Hence, in this work, we focused on environmental monitoring devices as use cases for our novel technology.

4.1 Development

Chapter2 contains the analysis of some of the most signiﬁcant smart cities and their applications, along with some of the sensors required for achieving these applications. It was concluded that weather (humidity, temperature, pressure, UV levels, light) and air quality (Nitrogen Dioxide, Sulphur Dioxide, Particulate Matter) monitoring sensors along with magnetometer, accelerometer, gyroscope, ultrasound, microwave, camera, microphone, GPS, WiFi, Bluetooth, and LoRa are some of the most common sensors used for IoT applications. Some of these sensors can be connected such that they can be updated with newer models, using connectors such as the Grove ones [131]. Table 4.1 shows the sensors chosen for the ﬁrst prototype, along with their costs.

49 50 Chapter 4 Generic IoT device for an environmental monitoring use case

Table 4.1: The sensors chosen for the ﬁrst version of the generic IoT device.

Sensed quality Distributor Model Precision Price (USD, 2017) Distance seeed studio De-Lidar 1 - 10 cm 149.00 TF02 Temperature Adafruit MCP9808 ±0.25o C 5.15 Luminosity Adafruit TSL2591 188 uLux 7.2 Pressure Adafruit BMP180 0.03hPa / 0.25m 10.3 Ultra Violet Adafruit Si1145 10.3 Humidity Grove AM2302 0.1 %RH 15.5 Sound Thomann t.bone GC -40 dB ± 3 dB 17.0 100 Images Raspberry Pi Camera up to 240 frame/s 30.0 Foundation Module Acceleration and SparkFun MPU-6050 2048 - 16384 LSB/g 41.3 Orientation 16.4 - 131 LSB/o/sec SO2 Alphasense B4 15 ppb 55.0 NO2 Alphasense B4 0.1 ppb 55.0 Particulate Alphasense OPC-N2 277.0 Matter Location Adafruit Ultimate -165 dBm 39.95 GPS

The majority of these sensors have been chosen because they have been proved to work with Raspberry Pi, the chosen SBC for the ﬁrst prototype, and because they are easy to use and have available documentation and libraries. Using Raspberry Pi 3 was a decision made based on availability, price, and the required features for this project, such as processing power and cost. This is not the ﬁnal Single Board Computer (SBC) choice.

The Alphasense gas sensors have been chosen because they are a popular choice in literature, their readings have good accuracies, and their cost is within the range of this project. They could be used to complement the existing air pollution monitors provided by city councils [33].

4.2 Theoretical use case - Southampton Smart City

This section presents a theoretical use case in Southampton in order to illustrate the beneﬁts of a generic device. This use case has not been implemented and it is only used for presenting the beneﬁts of generic devices deployed at a large scale in smart cities.

For the purpose of this example, it is assumed Southampton has 1000 generic IoT devices that contain the sensors described in table 4.1. The devices are spread throughout the Chapter 4 Generic IoT device for an environmental monitoring use case 51

Figure 4.1: Map of Southampton taken from OpenStreetMap [113]. city along main roads, near schools, airport, and in the Common, please refer to ﬁgure 4.1 for a map of Southampton.

The sensors along roads perform air quality monitoring, speed monitoring, and plate number recognition during the day. During the night, they control street lightning and perform air quality monitoring.

The sensors near schools perform air quality and security monitoring during school activity and weather monitoring otherwise.

On the Common, the sensors are used for weather and air quality monitoring during the daytime. During the night, they perform street lightning control, detect WiFi devices, and make use of the cameras for public security.

The sensors near the airport are used for noise and air pollution monitoring at all times.

This example shows how the same device is used for diﬀerent purposes within the city, which are part of the same infrastructure. It also shows that the devices can be deployed around the city without the need for a deﬁned purpose before deployment.

The device can also make use of the sensors it contains to change its purpose on demand, performing temporary functions. The following paragraphs illustrate two examples of situations when the sensor can be re-purposed. 52 Chapter 4 Generic IoT device for an environmental monitoring use case

There is a 5K marathon on Southampton Common July every year, and some of the generic devices are re-purposed for taking pictures at the event and for monitoring the UV levels. The devices will be used for these sole purposes during the event, and they will return to their initial activity after the event ends.

The City Council wants to optimise the salt spreading on the roads during the winter period. Some of the sensors along the main roads are re-purposed to monitor the weather conditions. They re-gain their initial functions during the other seasons.

4.3 Air quality monitoring

Air pollution is becoming a big concern across the whole world. China is ﬁghting against air pollution every day [63]. Complex systems have been designed for households to help the population keep safe, such as multiple air monitoring devices per home and air ﬁltration.

Cities in Europe are also concerned about the level of air pollution and are developing projects for monitoring air quality and a better understanding of air pollution. As noted in the literature review, Chapter2, cities such as Amsterdam, Zurich, Stuttgart, London, and Singapore are already working towards building air quality monitoring devices to be spread through the cities and give a better understanding of pollution distribution.

Air quality monitoring is one of the key concerns for future smart cities. We consider that having a generic IoT device that is able to perform air quality monitoring is essential, which is why the ﬁrst sensors that have been incorporated and tested are air quality sensors.

The major air pollution gases are Nitrogen Dioxide, Sulphur Dioxide, and Particulate Matter. High end, expensive, air quality monitoring devices that collect data about these gases are already present in most cities, for example, Southampton has three air quality monitoring devices. Due to their high prices, too few of these devices are present, and they are not enough to get an understanding of the air quality in the whole city, which is a common problem in the UK and other countries in the world.

We identify the need for having low-cost mobile IoT air quality monitoring devices that would collect data at multiple locations across cities. In this research, we have developed a mobile, battery-powered air quality monitoring device that was demonstrated at the Engineering and Science day at the University of Southampton to collect data on an uni-link bus, and we now present some further details of it. Chapter 4 Generic IoT device for an environmental monitoring use case 53

UDP Web socket Webpage Sensor reader Server (local network)

UDP Save data

Sqlite

Raspberry Pi device Cloud server

Web socket Webpage Server (public)

Save data

Sqlite

Figure 4.2: Device architecture for the preliminary test, showing how the data was collected, stored and displayed.

4.4 Preliminary testing

This subsection describes the preliminary tests of the air quality monitoring device at the University of Southampton Science and Engineering Day. The subsection describes implementation details, the data collected, how the demonstration impacted the public, and the lessons learned from this activity.

4.4.1 Implementation

An air quality monitoring device has been designed and built for a demonstration at the Southampton Science and Engineering Day. It contained Nitrogen Dioxide, Sulphur Dioxide, Particulate Matter, Pressure, and Temperature sensors. The client streamed live data to a cloud server via UDP, which displayed the real-time data stream on a web page that contained three charts (Air Quality, Temperature, and Pressure) and logged all the data collected in an SQLite database. The server was replicated locally on the Raspberry Pi client, for redundancy in case of Internet failure. Figure 4.2 shows the architecture of the device.

The client was written in Python using popular libraries, such as the Adafruit library for the MCP3008 ADC adapter chip to read the data from the sensors.

The server was written using JavaScript and node.js, and the graphs have been generated using the JavaScript Chart.js library.

UDP was chosen as a data transmission protocol for its simplicity and to support the data being collected and displayed live, which means that having the data sent continuously was more important than not losing any of the data. We are aware that this system, although reliable enough for its intended purpose at the time, is not secure enough and would require enhancement if deployed more widely. 54 Chapter 4 Generic IoT device for an environmental monitoring use case

The client is a Raspberry Pi 3 Model B. For the air quality monitoring, we chose Al- phasense sensors: the A4-series for the Nitrogen Dioxide and Sulphur Dioxide with the 2-way sensor circuit. The 2-way circuit is an in-house integration circuit made by Al- phasense for the two sensors to have minimal noise and for better integration with other circuits. The Plantower PMS1003 Particulate Matter [72, 127] monitoring device was also used. These sensors have been used for the report of quality vs. price they are providing. According to literature, these sensors give good sensitive values that can be used as a good and reliable reference for air quality.

4.4.2 Data

From the data collected during the experiment, it can be noticed that the gas readings, figure 4.3, and the Particulate Matter ones, figure 4.4, are most of the time within the healthy threshold. The only times when the limits are exceeded were when the device was placed close to the exhaust pipe of a bus, first peak, and close to the exhaust of a 1996 Diesel car. These results are expected, and it can be concluded that the sensors’ readings are sensitive within the healthy threshold, they can detect when the air has healthy, low amounts of the monitored polluting gases and when values exceed these values. These sensors are not meant to provide absolute values for air quality, but they can be used as references for when the air quality is changing.

Another observation made during the experiment is that the sensors readings are greatly aﬀected by pressure and temperature variations, and by comparing the four graphs, ﬁgures 4.4, 4.3, 4.5 and 4.6, it can be noticed that peaks in the gas and PM readings can be correlated with peaks in the temperature and pressure readings.

From ﬁgures 4.3 and 4.4, it can be noticed that NO2, SO2 and PM2.5 sensor readings are following the same trend with the same peaks and stable periods, although there is no real reason why the three should be so closely correlated during the experiment. All the sensors measure diﬀerent gases, and although the peaks are caused by highly polluting events, an increase in particulate matter is not necessarily related to an increase in SO2 and NO2. This leads to the conclusion that the reference voltage for the sensors was varying during the experiment, causing some noise in the data.

Furthermore, the sensors were placed in a box, and ﬁgure 4.5 shows how the temperature rises due to the Raspberry Pi heating up during operations. The sensors are temperature sensitive, and a future design should take into consideration this ﬁnding.

4.4.3 Security and Privacy

The air quality monitoring device has been mainly developed for exploring the research requirements of the generic IoT device presented in this work and has been used for an Chapter 4 Generic IoT device for an environmental monitoring use case 55

Figure 4.3: Graph showing the variation of Sulphur Dioxide and Nitrogen Diox- ide over time during the preliminary testing - the peaks are recorded when the device was placed at the pipe exhaust of a bus and a car respectively.

Figure 4.4: Graph showing the Particulate Matter 2.5 variation over time during the preliminary testing - the peaks are recorded when the device was placed at the pipe exhaust of a bus and a car respectively. 56 Chapter 4 Generic IoT device for an environmental monitoring use case

Figure 4.5: Graph showing the temperature variation over time during the preliminary testing

Figure 4.6: Graph showing the pressure variation over time during the preliminary testing. Chapter 4 Generic IoT device for an environmental monitoring use case 57 outreach project at University of Southampton. The outreach project was short lived and did not handle any sensitive data. As such, security and privacy concerns were only considered in the context of future versions and larger scale deployments.

The data collected during this experiment is not of a sensitive nature and it has been collected during an outreach project which aimed to show the public the importance of science in our lives. Hence, loss of data and accuracy were not signifcantly important for the experiment. The two main security measures taken for this experiment were keeping the system behind the University network without any sensitive public endpoint and following good practices for server (and Raspberry Pi) conﬁguration: changing default passwords, adding SSH keys for our user accounts, and only listening to the network addresses and ports we needed. A public URL for the online webpage was made available in case the demonstration device had to use mobile data to show the dashboard as opposed to eduroam. For the short-lived demonstration this proved to be suﬃcient. For a more permanent (or repetitive) deployment more measures need to be taken, such as encryption of the data in transit (to prevent both evesdropping but also inserting malicious readings into the system).

Data reliability can be improved for a larger deployment by using a reliable message broker that could handle queuing messages in the case that the network connection of the sensor node goes oﬄine. This has only been handled in the demonstration by running two server instances, one on the sensor node (the Raspberry Pi) and one on a diﬀerent server (see Figure 4.2). However, there was no synchronization between the two databases to handle missed or duplicate data points.

4.4.4 Outreach

The project was demonstrated at Engineering and Science day at the University of Southampton on the 18th of March 2017. We spoke to approximately 20 families (approx. 50 people) that participated at the event.

Families were composed of parents and their children in middle school or younger. Most of the parents seemed to understand air pollution, and the children, although too young to fully understand and relate to the implications of our project, seemed excited to interact with us, take part in our demonstration and try to understand what we are doing. Everyone seemed to be impressed with the whole event and enjoyed the activities and projects at the University.

Visitors found value in the Air Quality monitoring project, most of them mentioning how worried they were with the recent news on Air Pollution in the UK and how the project could help gain a better understanding of overall air quality within the city. They expressed interest in the visualisation software used for displaying data in real-time, the sensors, and the architecture of the monitoring device. The majority of people knew 58 Chapter 4 Generic IoT device for an environmental monitoring use case

Figure 4.7: Example of the charts used in the preliminary testing; the data shows how the particulate matter readings rise when amount of dust particles in the air increases. what a Raspberry Pi device is. Part of the visitors were able to identify current issues of Internet of Things devices such as power provisioning in restricted environments.

Children seemed to be impressed with changes in the data. For example, we asked them to find a way of generating dust particles, such as shaking their clothes or their chairs and follow the graph changes for air particle monitoring. Figure 4.7 exemplifies the data behaviour in one of these situations. We also asked the bus drivers to turn on the engine while we put the air quality monitoring device close to the exhaust (nobody was standing behind the bus at any moment while the engine was running) to show visitors how the Sulphur Dioxide, Nitrogen Dioxide, and Particulate Matter are increasing and the effect of vehicles on air pollution.

One of the most interesting conversations we had was with a teacher who found the project very interesting and thought that it could beneﬁt schools as a citizen science project. She also thought that having kits for students to build their own air quality monitoring devices would be an excellent educational program.

Overall the whole activity was a success. Everyone seemed to enjoy themselves, and it was a good way for us to gain feedback on our work while trying to explain the impact the technology can have on society.

4.5 Lessons learned

In conclusion, the outreach bus demonstration was useful, showing that the air quality sensors readings are sensitive enough to be used for complementing the high-end air Chapter 4 Generic IoT device for an environmental monitoring use case 59 pollution monitoring devices, that are not enough for a good understanding of the air quality. The sensor readings are not accurate enough to provide absolute values for air quality, but they can be used to detect changes in the environment. It was conﬁrmed that the temperature and pressure variations have an eﬀect on the quality of the sensors’ readings. This experiment also showed that a more stable circuitry needs to be implemented.

The system presented in this work meets the extensible requirement, as new applications can be deployed using the existing sensors. Adding new applications allows extending the scenarios the device can cover. However, a device with a limited number of sensors, permanently soldered on the board, is not enough, as new sensors with signiﬁcantly better qualities can be developed in the future, rendering such a device of limited use. Hence, updating the system in such circumstances would require updating the whole infrastructure, which implies that the customisation requirements are not met. The device needs re-designing due to the voltage irregularities illustrated in this chapter. In order to change the circuitry, the whole device needs to be changed, or a time-consuming process of de-soldering the components would need to be employed. Scaling this process is expensive and time-consuming. Hence the maintainability requirement is not met also.

All the work done so far has demonstrated the need for a modular system, where new technologies can be integrated during operation instead of building a device with a large number of sensors, which might not necessarily be needed or could become outdated. The literature review presented in Chapter2 presents a method for achieving these requirements. Table 4.2 presents detailed methods for achieving the design requirements introduced in Chapter3. 60 Chapter 4 Generic IoT device for an environmental monitoring use case

Table 4.2: Methods for achieving the design requirements - customisation, expansion, maintenance and accessibiliy- hw represents hardware and sw represents software

Level Method Explanation Hw Flexible, reliable IoT is a fast paced area, which is why building de- hardware architecture vices that enable easy hardware upgrades would further its evolution. Sw Flexible, resilient OS Most of the IoT OSs are designed based on the one- size-fits-all mentality or they are proprietary and cannot be customised easily. Neither of these options is optimal, and we need an OS that can be easily customised for each individual application it is meant to run and it should also be easy to modify as needed during operation. Sw Secure, robust OTA OTA updates are critical for a long-lived system as updates. they provide essential bug fixes, security patches but also functionality upgrades (adding new features) and compatibility with newer software. Enables management of multiple versions of the OS simultaneously to aid managing an entire fleet of devices. Sw Separation between Flexibility in application development and portabil- the OS and applica- ity; eases deployment and management of applications tions. Sw Remote management Enables monitoring the devices, installing updates, of devices. changing configuration parameters and installing, removing, starting or stoping containerised applications. Chapter 5

Hardware architecture

In the previous chapters, we identiﬁed the design requirements and technologies required for building the next generation IoT device, Table 4.2. This chapter presents an implementation of this device and the required technologies at the hardware level. The next chapter explores modularity at the software level.

5.1 Introduction

Hardware is developing rapidly, and its availability increases. For example, the Raspberry Pi computer series, which was released on the market in early 2012, has impacted the IoT development signiﬁcantly - giving birth to important IoT projects in the hobbyist world [74], academia [42, 68, 13] and industry [47].

Indoor positioning is another example of technology that has evolved rapidly, from using one sensor like WiFi or Bluetooth to using multiple ones, i.e., adding gyroscope and accelerometer. Networking technologies like LoRaWAN are oﬀering large scale networking and positioning. This evolution has led to better, improved, and advanced IoT technologies and services and made older ones obsolete. Hence, in this work, we are presenting a device that can adapt to these fast technological advances in order to save time, money and to lead to the fast development of new IoT devices and services.

5.2 Motivation

Developments in hardware lead to new IoT products, which appear on the market at an increased rate - each of them with better performance than previous ones. Over the last ﬁve years (2014 - 2019), 11 models of Raspberry Pis have been released as part of ﬁve Raspberry Pi families: 1, 2, Zero, 3, and 4. Each release brings improvements such

61 62 Chapter 5 Hardware architecture as better processing power, new capabilities such as included WiFi and Bluetooth and, in the case of the Zero family, smaller size and lower cost. This hardware evolution is beneficial for IoT development, but it also has a negative impact on sustainability and increases the complexity of managing IoT devices. Every year, nearly 50 million tonnes of e-waste are produced globally, out of which approximately 40 million tones end up in landfill, and it is expected that by 2021 the annual e-waste volume will surpass 52 million tones [115]. A significant part of this e-waste is generated by IoT devices. IoT has a positive impact on sustainability, showing a strong correlation with 11 of the 17 Sustainable Development Goals (SDGs) [111]. IoT negatively impacts on responsible consumption and production, the 12th SDG, [57]. The UN has proposed tackling this issue by creating a circular economy. The development plan for 2050 Smart City London emphasizes being able to re-use existing infrastructure instead of disassembling it, and installing a new one and using infrastructure for multiple purposes are two of the main goals of the project [56].

Based on the work done in the ﬁrst steps of this project, we have identiﬁed the requirements and methods necessary for building IoT devices with an increased life span and reduced management complexity. The reference architecture presented in this work can be used at the base of a circular economy and reduce the negative impact IoT has in SDG 12.

5.3 Proposed Solution

Re-purposing and updating hardware is a big challenge that has not been explored enough in the literature up to this point. Although there are companies that are trying to build plug and play devices that essentially allow users to add, change and update hardware, they are still limiting the user to a small range of proprietary sensors that can perform speciﬁc tasks [88,8].

The main component designed and built in this work is a plug and play development board, PiSEB, illustrated in Figure 5.2, that has a modular design, as depicted in Figure 5.1. It allows access to multiple interfaces, such as SPI, I2C, UART, via plug and play sockets. The sensors can be attached using JST connectors to any of these sockets. It also has connectors for a microcontroller and/or a Single Board Computer (SBC) - it currently has been used with Raspberry Pi and PyCom/Fypi, but it can be be used with other single board computers and microcontrollers with the same pinout or using an adaptor. This is the second iteration of the board and schematics for both versions can be found in Appendix A and Appendix B respectively. Additionally to the interfaces shown in Figure 5.2, the board has the following features:

• Wide range of voltage input 12V - 24V. Chapter 5 Hardware architecture 63

Minimal OS

App 1 ... App N

Remote Over the air updates Container engine management client

>_ Kernel Flexible, modular software

Flexible, modular Processing/Computing board hardware

Plug&play sensor/actuator Storage Wireless comms comms extension

S1 S2 S3 S4 ... Sn

Figure 5.1: Reference architecture, highlighting focus of this chapter implementation, the architecture at hardware level.

Figure 5.2: PiSEB development board [12] designed as part of this research, where the continous line delimitates the microcontroller (pycom) and SBC (Raspberry Pi) interfaces 64 Chapter 5 Hardware architecture

• Reverse polarity protection.

• Remote control for the Raspberry Pi (via the microcontroller).

• EEPROM for each Raspberry Pi, adhering to the Hardware on Top (HAT) speci- ﬁcations [90].

• Debug/status Light Emitting Diodes (LEDs) that can be disabled to save power.

• micro-SD card extension for the Pycom microcontroller.

• On-board real-time clock.

• On-board DHT22 temperature and humidity sensor.

The board has been designed in Eagle, the schematics are open-source and can be accessed on Github [12] in order to allow uptake in the IoT community.

For this project, we have built and tested twelve of these boards with the purpose of developing environmental monitoring devices to be used across Southampton for air quality and weather monitoring. This is not the only use for this board, and it can be used for any application across a smart city, as there is no restriction on the input sensors. It can also serve as a testbed for IoT technologies, generate collaborations between researchers, and can be built by anyone in the world given its open-source availability.

5.4 Environmental monitoring example

The environmental monitoring device, shown in Figures 5.3a and 5.3b, has been built and tested in order to prove the applicability of the PiSEB board for IoT devices. The sensors used for this example are detailed in Table 5.1. An environmental monitoring use case has been chosen for this prototype due to the increasing concerns in today’s society regarding air quality and weather.

The type of sensors used for this example has been chosen based on the literature review of smart city applications. The sensors are generic, widely available and can be used for a wide range of IoT applications, allowing face validation of diﬀerent characteristics of the system architecture presented in this work.

The majority of these sensor models have been selected because they have been proven to work with Raspberry Pi, the chosen SBC for the prototype, and because they are easy to use and have available documentation and libraries. For communications, the Pycom FiPy has been chosen as it provides LoRa, WiFi, Bluetooth, Sigfox, and cellular LTE-CAT M1/NB1, which costs 62 USD at the time of development. Chapter 5 Hardware architecture 65

(a) Selection of sensors used in the generic (b) Atmospheric sensing housing environmental monitoring box, showing a for environmental monitoring de- particulate matter monitoring sensor (left), vice built as a use case for the ref- CO2 monitoring sensor (center) and a mi- erence architecture. crophone (right) on the structure used inside the Stevenson cage.

Figure 5.3: The hardware used for the environmental sensor prototype.

The Alphasense gas and particulate matter sensors have been chosen because they are popular in literature [31], provide good quality at a reasonable price, their readings have good accuracy. They can be used to complement the existing air pollution monitors provided by city councils.

The Raspberry Pi 3 Model B+ (Raspberry Pi 4 Model B was not released at the time of this work) has been chosen because it has the required speciﬁcations for this project. This is not necessarily the ﬁnal SBC choice. Considering the rate of hardware advances during the last few years, building a device that can be upgraded once new hardware becomes available is essential, which is why we are designing the device presented in this work such that both hardware and software allow for upgrading.

5.5 Face validation - results and conclusions

The environmental monitoring device has been deployed on the roof of Building 176, Boldrewood Campus, the University of Southampton, in order to validate the design. 66 Chapter 5 Hardware architecture

Table 5.1: The sensors chosen for the environmental monitoring IoT device, where the last three sensors were added after deployment; prices presented are the ones at the time of the writing.

Measurement Sensor Price (USD, 2019) Distance Seeed Studio De-Lidar TF02 149 Luminosity Adafruit TSL2591 7 Pressure Adafruit BMP180 10 Ultra Violet Adafruit Si1145 10 Sound Thomann t.bone GC 100 17 Images Raspberry Pi Foundation Cam- 30 era Module NO2 Alphasense B4 55 Particulate Matter Alphasense OPC-N2 277 Location Adafruit Ultimate GPS 40 Temperature Adafruit MCP9808 5 Humidity Grove AM2302 16 Acceleration and Orientation SparkFun MPU-6050 41

We used PoE for power and connectivity. The only use of the FiPy was to control the Raspberry Pi, e.g., rebooting when needed, but it is planned to be used in the future for LoRaWAN connectivity. The sensors were used out of the box for the purpose of this application, with the exception of attaching JST connectors, where needed.

The environmental monitoring device consists of two components: one stevenson cage with a dome on top for the air quality and weather monitoring sensors and a waterproof enclosure with the PiSEB board and computing units, as depicted in Figure 5.4.

The plug and play and modularity of the board allowed for extended testing of the sensors, and it eased upgrading the hardware, for example, upgrading from Pycom Lopy to PyCom Fipy. It also allowed for ease of building multiple versions of the device, where some of the sensors presented in Table 5.1 were omitted - these versions are not presented in this work as they have not been deployed yet.

The main advantage of the PiSEB board drawn by this experiment is the ability to field test sensors that otherwise would have been used for large scale deployments without the possibility of modification. For example, the Alphasense OPC sensors, although presenting important advantages and working reliably in laboratory settings, have been found unreliable during field testing due to incomplete readings and high power usage [31], hence they could be easily changed for more reliable sensors.

Another advantage presented by using the modular, plug and play PiSEB board was the ability to use a high number of sensors concurrently and explore power usage and computing capabilities, while experimenting with data collection rates and diﬀerent sensors and interfaces, for example, the Alphasense can be used via USB or SPI, and using the Chapter 5 Hardware architecture 67

Figure 5.4: Reference architecture, highlighting focus of this chapter implementation, the architecture at hardware level.

PiSEB board has allowed us to understand that using the sensor with the SPI interface presents a more stable, reliable connection.

Three weeks after deployment, it was concluded that the on-board DHT22 humidity and temperature sensor was prone to failure due to environmental conditions and did not offer long-term reliability. The air quality sensor readings are influenced by humidity and temperature; hence the DHT22 sensor readings are essential for the presented application. As a result of these findings, new humidity and temperature sensors have been added to the device, as detailed in Table 5.1. The new sensors were added via the plug-and- play sockets available on the PiSEB board, in the Stevenson cage in order to obtain more relevant results for this application. The example illustrates the maintainability, and customisability of the architecture presented in this work. The device was modified after deployment to replace the faulty sensor with better-suited ones, similar or entirely different from the replaced sensor. Traditionally, the entire device is replaced for another one, which means that all the ten sensors, extension board, and computing modules become part of the e-waste, despite most of them being fully functioning. Other modular architecture systems are not flexible enough to allow changing a sensor for another model, usually having a limited range of sensors they can support. The modular architecture presented in this work saved 13 electronic modules, 100% of the functioning modules, and 92.3% of the total device electronic modules, leading to increased the lifespan of the device. For this exercise, an electronic module is defined as one sensor, one computing board, or the PiSEB extension board, and each of them can be replaced separately in case of failure. 68 Chapter 5 Hardware architecture

Table 5.2: Summary of face validation tests and results. For this exercise, an electronic module is deﬁned as one sensor, one computing board, or the PiSEB extension board, and each of them can be replaced separately in case of failure.

Design Test Result Requirements

Customisability Temperature and humid- In-ﬁeld testing and building of new ity sensors upgrade to technology and applications Adafruit MCP9808 and Grove AM2302 respectively Extensibility An orientation and accel- 66% less electronic modules needed eration sensor was added to deploy new application to the device after deployment Maintainability In-ﬁeld replacement of Save 100% functional electronics and DHT22 faulty sensor 92.3% of the total electronic modules

Availability Board resources available World-wide availability open-source. Board plug and play design does not require expert knowlege to utilise. Any sensors can be used, and there are no vendor-speciﬁc requirements.

An additional acceleration and orientation sensor has been added to the device using the plug-and-play board designed and built in this work, PiSEB. Testing and debugging without disrupting the existing applications or aﬀect the robustness of the device. Adding a new sensor to the existing device allowed using existing infrastructure for building and deploying new applications. The implications of this extension are: saving time and costs, reduced deployment complexity, reduced management complexity. Traditionally, enabling new applications for smart cities requires new devices and infrastructures to be deployed - in the presented case, at least one computing device, one sensor board, and one sensor. The presented architecture reduces the number of deployed electronic modules by 66%.

In conclusion, the hardware design presented in this chapter, designed and built following the reference architecture proposed in this work, meets the design requirements (customisability, extensibility maintainability and availability) identiﬁed in this research. These ﬁndings are summarised in Table 5.2. Chapter 5 Hardware architecture 69

5.6 Known issues and limitations

The PiSEB has a wide range of interfaces in order to cover a wide range of sensors, but this can also impose limitations. The board can be too bulky for some applications, which can be solved by accessing the open-source ﬁles of the board and re-building it with a lower number of interfaces. On the other hand, other applications could require more interfaces and can be solved similarly using the open-source ﬁles.

The PiSEB is a generic board that tries to cover a wide range of sensors by providing plug and play accessibility to diﬀerent interfaces. However, some sensors might need diﬀerent interfaces, and as a result, they cannot be attached to the board.

The plug and play sockets are JST, but not all the sensors come with JST connectors built-in. Hence these might have to be attached before using the board.

The board allows for connecting a wide range of sensors, but electronic knowledge is required in order to use the board at its full capabilities, as having a large number of sensors within a device could cause errors due to wiring, interference, power usage, or computing power requirements.

The PiSEB can be used with any microcontroller and SBC. However, the pinout used for attaching these are the ones used by the Pycom microcontrollers and the Raspberry Pi, hence attaching something with a diﬀerent pinout might require an adapter or building another board using the open-source ﬁles.

The PiSEB has been developed and built for minimising the complexity of adding new technologies to existing distributed sensors networks, but it still requires minimal physical intervention in order to update any of its hardware components.

The number of sensors that can be used within an application is also limited by the capacity of the computing unit.

Chapter 6

Software architecture

This thesis proposes using modular hardware and software architectures for reducing the complexity of managing distributed sensor networks in the era of constant technological advances, where building on top of current architectures needs to be made a priority in order to enable better management of these devices, but also to enable further technological enhancement of existing systems.

In the previous chapter, we discuss an open-source modular hardware architecture, that allows updating the computing unit and the sensors, and is not limited to any proprietary technology, answering research question 1. To complete this type of device design, in this chapter, we are developing a modular software architecture that can be used independently or concomitantly with the hardware architecture presented in the previous chapter of this thesis, answering the research question 2.

6.1 Introduction

The IoT can be the solution to many challenges in the current socio-economic environment. For example automatic water meter reading by driving a car on the street [136], mobile air quality sensors to get a better understanding of the air pollution in the cities and its origins [85], citizen science projects such as weather stations and air quality monitoring devices are just a few projects that have a high impact on society and are models of distributed sensor networks in restricted environments.

Deploying and managing such devices is a challenge, and problems related to the power supply, software updates, and recovery in case of failure can arise in restricted environments when we cannot easily access the device. This chapter is looking into ﬁnding ways of deploying and managing distributed networks of IoT devices. It presents a software architecture that is designed to be used for large distributed networks of IoT devices operating under restricted environments. The chapter explores existing tools that can

71 72 Chapter 6 Software architecture be used to design more reliable IoT devices and proposes an architecture that aims at reducing the complexity of managing smart devices and related emerging technologies.

Our architecture has three main modules: Over the Air (OTA) updates, Operating System, and containerisation. The solution proposed here is not revolutionary, but rather evolutionary. Others have introduced similar concepts, but they are either designed for cloud servers [109] or do not support popular embedded systems architectures [103]. Furthermore, our overall hardware and software architecture presented in, Chapter5 and this Chapter, aim to encompass the whole modular architecture required.

The most similar architecture is that of [71]. Their solution has been tested at the initial stage of this project and has been proven to be less flexible and too complex for the purpose of this research, as described in chapter2. For example, BalenaOS, although very similar to what we are building, cannot be easily integrated with other packages or modules other than the ones developed by the same company, specifically for their proposed architecture. The main similarities between BalenaOS and the OS built-in this work are modularity, minimal Yocto built OS, over the air updates, and containerisation. However, BalenaOS - although built with Yocto - is generally a few versions behind the latest stable Yocto development, and customising the factory-built is not straightforward, which restricts most of the users to use it as provided, along with their proposed solutions for either of the modules. This, although not contradictory to the modularity they are claiming, does not allow free choice for the technologies used in each of the OS modules. The over the air updates provided by BalenaOS are Docker-based (in the sense that the updater itself runs in a container) and use a dual image system. In this work, we have tried to integrate other OTA technologies with the BalenaOS (OSTree-based incremental updates), but this was proven to be too complex and time-consuming, requiring low-level modifications of Yocto layers to solve compatibility issues. The nature of the Balena built requires its own customised containerisation engine, which conflicts with any other type of engine a user might choose instead. All of these difficulties have proven that, although based on similar ideas presented in this thesis, the Balena technologies are not as flexible as required for our work, and the development based on their layer was aborted. A key difference between our solution and balenaOS is that our solution encourages modifying the OS if required and the incremental updates system enables complex fleet management with devices being able to run different versions of the OS on demand (and, for instance, changing between them at boot or having different OS branches for different sets of devices). Our containerisation module, albeit recommended for ease of deploying and managing applications, is entirely optional.

The architecture proposed in this chapter is based on open-source stable IoT tools that are already available and have been proven to be reliable for embedded devices. The main purpose of this project is to prove the need for modular hardware and software architectures for reducing the complexity of managing distributed sensor networks and Chapter 6 Software architecture 73

Minimal OS Yocto-based

App 1 ... App N

Remote Over the air updates Container engine Cockpit OSTree Docker management client

>_ Kernel Linux Flexible, modular software

Flexible, modular Processing/Computing board hardware

Plug&play sensor/actuator Storage Wireless comms comms extension

S1 S2 S3 S4 ... Sn

Figure 6.1: Reference modular architecture, showing the main technologies used for the software implementation. Please note that these technologies are examples, as the main advantage of the architecture presented in this work is not being locked to any speciﬁc technology. ease their development, and the speciﬁc tools used in our applied example are just suggestions, while other tools might be more suitable for other projects.

6.2 Requirements

Table 4.2 identifies the technologies required for implementing a system architecture that meets the design requirements identified in this work and follows the reference architecture. This chapter focuses on the software level, as shown in Figure 6.1, presenting a method of implementing the reference architecture with applications in environmental monitoring. The specific technologies used for this implementation are just examples, and better or more suitable ones can be added at a later stage, as the main goal of the presented architecture is not locking a potential user to any specific technologies.

6.3 Operating Systems

The current OS distributions for SBC, such as Raspberry Pi, are not built for large scale deployments having increased size due to user-friendly features and lacking the required speciﬁcations for large deployments, such as reliability in case of power failure. Most 74 Chapter 6 Software architecture

SBCs have constrained resources, which is why a large operating system with built-in libraries and applications, such as Raspbian, cannot be eﬃciently used for production. These Operating Systems (OSes) are made for out of the box operations, for exploring the capabilities of the boards and for ease of deployment for educational projects or the hobbyist community, which is why they contain libraries and binaries that are most of the time not necessary for the applications they are running when in production, increasing their size and complexity.

The Yocto project [125] gives flexibility for building customised Linux distributions. The Yocto project was developed based on the OpenEmbedded project and allows creating and modifying Linux distributions. The deployment can be done directly on the hardware or using SSH. The Yocto images are built using Bitbake. Bitbake is the task executor and scheduler used by the OpenEmbedded build system to build images. Bitbake also allows building multiple targets at the same time, where each target uses a different configuration. The image build can be done via the terminal or using the Yocto project web interface, Toaster. The project is popular, and it supports builds for a wide range of machines and software packages. However, using the Yocto project also has some disadvantages. Every change requires a new built, for example, adding a new package. Furthermore, not all Linux packages have Yocto layers or recipes, and some of them are unmaintained or have very specific requirements that lead to incompatibilities with a high number of other packages. For example, the meta-virtualization layer for building Docker on a Raspberry Pi is still under development and can cause problems during the building process or after. Furthermore, the bitbake compiler, as well as the more user-friendly compiler built for the Yocto Project Toaster, require a high learning curve. The error output logs do not offer enough information for efficient debugging, making the development process time-consuming and complex.

The biggest software component is a minimal OS built using the Openembeded Yocto project, the Rocko branch (latest stable at the time of the last upgrade of our stack; we regularly upgrade our OS development stack to the latest stable versions of packages and poky branches) of poky. Yocto gives advantages such as flexibility around building an application-specific OS. It allows adding capabilities such as read-only root filesystem and OTA updates, avoiding clutter, and keeping a minimal size OS. It enables building the same OS for different boards. At the moment, the OS built for in this work has been built and tested for Raspberry Pi 2, Raspberry Pi 3, Raspberry Pi 3 Model B+, and the Up-Board.

The OS can be used as provided or can be further customised to ﬁt the requirements of the project it is being used for. The core capabilities of the OS are OTA updates, containerisation via Docker, and device management with Cockpit. Chapter 6 Software architecture 75

6.4 Remote device management

The Cockpit is a modular server management tool that can be easily extended via plugins. It provides a server-to-server (device-to-device) communication model based on SSH. It officially supports plugins for managing Docker containers, storage administration, network configuration, inspecting logs, and provides easy in-browser terminal access. For this work, a plugin has been developed and implemented in order to enable interaction with OSTree. Any of the devices registered in the Cockpit “network” can be configured to (passively) listen to an HTTP port. The Cockpit shows a web page that allows administrators to see all the devices set up with Cockpit.

The Cockpit client has been built into the OS using the meta-remote-management Yocto layer [10]. The meta-remote-management is an open-source layer that has been developed and implemented as part of this project. For this validation stage, the server has been tested and run on an internal server, in the ﬁrst stage, and then it was moved to a cloud server.

6.5 Over the air updates

In Chapter2, three types of OTA systems have been introduced: full image updates, incremental updates and container-based updates.

Full-image updates systems work by dividing the storage space into more partitions, usually two: A and B. One is the primary partition, which the systems run from, and the other one is used to download and apply an update when needed. If the update fails, the system falls back to the old partition. The downside of this type of system is the large bandwidth required for each update - typically downloading a full OS image with each update. Another disadvantage is the ineﬃcient use of SD card space; 50% of the space is only used when applying a new update and cannot be used for applications or data. For our system, we initially tested the Mender full image updates but decided that we wanted a solution that uses minimal bandwidth and maximises the space available for data, such that it can be used in more restrictive environments also. While full image updates need high bandwidth for deployment, which can be challenging to achieve in restricted environments, they oﬀer the advantage of entirely changing the Operating System, while the dual partition system can also be used in case of complete OS failure. The size of the update can restrict the pool of radio technologies that can be used for transmitting the updates. For example, LoRa has low bandwidth, but it has a high transmission range, between 20 km in LOS scenarios and 2 km in urban areas, which makes it a desirable technology for IoT sensor networks deployed in restricted environments [145]. 76 Chapter 6 Software architecture

Container updates refer to the system used to update container image, and they are ideal for application deployment and updates but not for the entire OS. We use Docker with a Docker registry to provide a way to deploy applications to a ﬂeet of devices.

For the final version of our software stack, we use a system of incremental updates called OSTree for the OS, which provides a way to send OS updates to clients efficiently (only send deltas, not entire images) and be able to manage entirely different operating systems (or OS versions) on the server-side and the client. The clients (devices) have a read-only root filesystem and a (git-like) repository of OS versions that can be used to boot. The update system manages which OS version the device boots into, and this mechanism can be used for recovery in case of failure. When applying an update, new files and metadata are downloaded to the repository, but old ones are not altered, thus if an update gets corrupted, previous versions should remain usable. The main advantage of incremental updates is a smaller size, requiring smaller bandwidth. Rollback to the previous version in case of failure is also possible. However, with this type of update, we can only make changes to the current operating system, and there is no option for recovering in case of complete OS failure.

6.5.1 OSTree

The core capability of the system is OTA updates using OSTree. This allows the OS to be updated remotely even after the initial deployment, and also supports working on multiple versions (branches) simultaneously.

OSTree provides “git for operating system binaries” [149], designed to parallel install multiple independent bootable Unix-like operating systems atomically. It is comprised of a userspace content-addressed filesystem and an administrative layer that atomically installs the OS. It records and deploys complete bootable filesystem trees, but has no built-in knowledge of how a given filesystem tree was generated, the origin of individual files, dependencies, or descriptions of individual components.

OSTree-based updates have two components: a client and a server. Read-only OS trees are replicated on the client by atomically downloading contents from the server. System crashes or power problems during the update operation do not lead to system corruption; the system reboots into the old version or the new updated one.

At the client level, OSTree deployments rely on a top-level OSTree directory. Each device has an OSTree repository and a set of deployments. The deployments rely on hardlinks into the repository. Hence each update would only increase the OS size proportionally with the new ﬁles only, plus some constant overhead. Applying delta updates on Android apps can reduce bandwidth with up to 50% [126]. The OSTree kernel parameter sets which deployment the device boots. The device will boot into a chroot equivalent that points to one of the deployments. The OSTree-based ﬁlesystem is described in Table 6.1. Chapter 6 Software architecture 77

Table 6.1: OSTree-based ﬁlesystem

Path Description

/usr Read-only bind-mount content to prevent corrupting the repository. The main advantages of such systems are reliability and predictability. /etc Read-write directory. A deployment default configuration, which is in /usr/etc, is copied into the /etc directory inside the deployment. An update is performed by a three-way merge between /usr/etc, /etc and the /usr/etc of the new version of the OS. This way, new defaults do not override current configuration if it was changed, but new configuration files are copied normally. /var It is preserved across updates, shared between deployments with the same OSNAME. Typically /opt, /src, /mnt, /usr/local are symlinks to sub-folders inside /var/ /home Indirectly symlinked to /sysroot/home (via /var/home), thus it is shared between all deployments. /sysroot Points to the physical sysroot.

OSTree also provides a C shared library that allows computing the contents of /usr directly on the client, assembles a new ﬁlesystem tree, and records it to the local OSTree repository.

The server-side can be a simple static HTTP(S) server that makes the bare/archive repository available. The OSTree client is then able to pull in the required metadata and ﬁles for updates. Static binary deltas can be pre-computed between speciﬁed versions to reduce bandwidth.

More advanced server software can be used. For instance, access to the repository can be restricted using an authentication mechanism such that only authorised devices can download the OS. Furthermore, access can be under ﬁne-grained access control for diﬀerent branches of the OS.

In the real-life application presented in this work, the OSTree client was built in the OS using the open-source Yocto layer meta-updater [6]. The OTA server was built, deployed, and tested on both an internal server and a cloud server. For simplicity, HTTP has been used at this stage, although for the large scale deployment, a more secure protocol will be implemented (i.e., HTTPS and authentication). A Cockpit plugin has been developed and implemented for monitoring and deploying the updates. 78 Chapter 6 Software architecture

6.6 Containerisation

Whilst containerisation is not new, Linux Containers (LXC) has been used by companies such as Google for application deployment for almost a decade , containerisation became much more popular and accessible over the last few years, since containerisation tools such as Docker have been released.

In the architecture proposed in this thesis, containerisation is used for providing an application layer to the devices, as presented in Figure 6.1. All applications run in a container, and they are isolated from each other and the host OS, with appropriate access to the required hardware peripherals (sensors, cameras, etc.). This method of deploying applications allows for easy remote management, deployment, and updates but also enables the development of applications in simulated environments, which is ideal for rapid prototyping and automated testing.

The main advantages of containerisation are:

• Reliability - deploying applications as part of isolated systems makes the system less prone to failures, i.e., if an application fails, it will not affect the other applications on the localhost. It also eliminates software conflict problems, driver compatibility, and library conflicts.

• Security - having the applications isolated from each other minimises the risks of having the whole system compromised due to security issues at the application level.

• Rapid Deployment - once the application is built within a container, it can easily be deployed on any hardware running Linux distributions. This also makes upgrading the hardware very easy.

• Ease of updating - the applications can be easily updated or upgraded, simplifying the process of re-purposing embedded devices systems.

• Minimising the size of the host OS - having applications and their dependencies deployed in containers minimises the size of the main OS, which makes deploying OS updates over the air much easier.

Adding a containerisation layer does have a cost: the need to have a container runtime available in the host OS but also that each containerized application is larger in size (container image + application size).

Container updates can be made within the container only, and, using the correct tools, anything can be changed from binaries and libraries to the whole application. We have decided to use containerisation for application deployment and management, which is used on top of the main operating system and its independent updating mechanism. Chapter 6 Software architecture 79

6.6.1 Applications in containers

The OS is conﬁgured to install Docker by default. Docker was chosen due to its ease of use, availability, and the wide range of tools built around it. All the applications are running inside a Docker container and are deployed via a Docker image. This sim- pliﬁes the development and deployment of applications and separates the core OS and dependencies from application-level code.

In this context, applications are programs that can interact with peripheral devices (such as sensors) attached to the host. For a device with a camera and a motion sensor, an example application is a program that reads values from the sensor and sends a request to a server when motion is detected; additionally, it records a short video and sends it to the server as well. Another application could analyse the video on the edge device in order to enhance privacy; for example, people counting [36].

This comes at the cost of having to support a container engine. Each application is larger in size due to being packed in a container image. For applications that share dependencies, this will result in having the same dependencies stored multiple times, once in each container. We consider that, besides the advantages listed above, avoiding dependency conflicts and offering the freedom of choice for programming languages and libraries, the ability to create and deploy applications that would work reliably on different host OS environments, and the ability to develop applications in very different environments than the deployed target, outweigh the disadvantages.

Each application container is stored in a Docker registry, located on the main server - in our case, the local and cloud servers, respectively. Each application can be tested before deployed in the ﬁeld while updating an application adds only the new layers that are not present on the device. The applications can be deployed on any of the connected devices via the Cockpit manager, which allows deployment and monitoring of the application containers. In the implementation presented in this work, multiple applications that read and process data from the sensors have been tested. The data was then sent to the server and stored in a simple database. During this validation stage, other available technologies have been tested, such as Microsoft Edge Compute - which is based on containerisation. It has been decided that at this stage of development, this type of platform is not useful due to lack of robustness, i.e., an intermittent connection between server and client.

6.7 Server-side requirements and considerations

The system requires a few components to be oﬀered on the server-side. These are a remote OSTree repository, a Docker registry to pull applications from, a server running Cockpit (not mandatory), and any components required by applications. 80 Chapter 6 Software architecture

The basic server-side solution used during this validation stage for the OSTree remote repository is a static HTTP ﬁle server making the archive OSTree repository available at a URL. This allows devices to pull updates when they become available in the remote repository. This can be protected using an authentication scheme. The system has also been implemented and tested on cloud services such as Microsoft Azure and Google Cloud Platform. A standard Apache HTTP server or Nginx server can be used.

Deploying applications via Docker containers requires a Docker registry. Docker registry is an open-source project that can be easily deployed on a server. Alternatively, Docker Hub offers free hosting for Docker images that are made public and paid options for private storage. All major cloud services providers also offer a hosted solution. For this validation stage, different solutions have been successfully implemented and tested: local server, Google Cloud Platform Docker registry, and Microsoft Azure Docker registry. Although all of them have been successfully tested, it has been found that the most convenient implementation was the one on the local server. Cloud solutions had the benefit of providing a ready-built solution; however, in our testing, it seemed to add unnecessary complexity. We acknowledge that cloud-based solutions might be favorable to self-hosted in large deployments due to ease of scalability; there is, however, a cost in development time to set up the clients to work with the chosen cloud provider.

Running Cockpit on a Linux server and adding all devices in Cockpit from the interface was found the most convenient method at this validation stage. The server SSH public keys were copied to the authorised keys ﬁle on all the devices to avoid typing passwords. This made Cockpit on the devices is more easily accessible, and the devices did not need to support the Cockpit web server. A potential problem with this is key invalidation in case the server’s private key gets compromised.

The applications running in Docker containers have their own server-side components, and there are many choices for how to implement data collection and processing pipelines. All major cloud providers have scalable solutions focused on IoT use cases - they provide advanced features like device provisioning, key rotation, and telemetry stream analysis. For small deployments, simple HTTP applications backed by a database would suﬃce. For this validation stage, both options have been successfully tested.

6.8 Power

The consumer SBCs highly available on the market are known for having power issues such as power consumption, power provisioning and are prone to power failures. At the moment, there is a lot of eﬀort in trying to produce devices that are more power-eﬃcient and reliable and to build batteries that last longer. Plus, using solar and wind power for IoT devices is a popular choice, especially when the devices are deployed in restricted environments. Power over Ethernet (PoE) is a popular choice for providing network Chapter 6 Software architecture 81 connectivity and power to IoT devices, but there is a limit to the amount of power the devices can consume when connected this way.

Both hardware and software are prone to power failure. For example, the Raspberry Pi can fail to reboot after a power failure when it runs the default Raspbian in the case that some of the configuration files get corrupted during power off.

In order to avoid this, we created a read-only root file system. This has been achieved using Overlay FS [51]. Overlay FS has been built into the Linux kernel since v3.18 and provides a mechanism to create a read-only root file system and then overlay a read-write file system on top. This can be built using Yocto.

Alpine OS was also considered for this work due to its small image size and read-only root ﬁle system [48]. However, it was not used due to the complexity of the process of adding new packages, like using a speciﬁc set of commands for making them permanent before the reboot, steps that could be easily overlooked during the development phase, as well as the small range of packages available to install in the Alpine package manager.

6.9 Implementation details - other technologies

We deployed a Mender server and built a client using the Yocto project that has been tested with Raspberry Pi 2 and BeagleBone Black. The complexity of building and deploying the system on the two devices is similar. The main diﬀerence between Raspberry Pi and BeagleBone Black is that Raspberry Pi supports a larger number of packages, while the BeagleBone built was limited to minimal capabilities due to incompatibilities between packages and number of features implemented. OS distribution for Pine64 can also be built using Yocto, but this is also limited.

Using Mender was a decision made based on availability, ease of deployment, and available documentation. Building the Mender client can be done via the Yocto project. The Yocto project only runs on Linux distributions and requires high storage memory for building images due to the number of files and directories created during the build. Building Mender into the OS distribution will increase the image size by 1GB. This is significantly high compared with the space the other packages occupied for the first client trial: 200MB.

Sending updates via Mender requires a new image to be built using Yocto. The image is compressed using a Mender tool called mender-artifact into an artifact that contains the new root filesystem and information about the update such as version and compatible devices. The artifact can be sent using the Mender server. The update is sent to the client, and once it has been installed onto the free partition, the device is rebooting using the new root filesystem. If the update is successful, the client communicates this to the server. Otherwise, if the client is not communicating with the server or the update is 82 Chapter 6 Software architecture unsuccessful, the client will rollback to the previous version at the next reboot. For the first test, we have successfully tested the Mender project by building the client and sending an update via the webserver.

However, due to the large size of the updates, it was decided that Mender was not suited for the type of application we are interested for this work. Hence, although it has been tested successfully, it was decided to be discarded in favor of incremental updates, OSTree.

For building, deploying, and managing applications, it was decided to use Docker as it is a very popular containerisation tool, very well documented with available tutorials, and can easily be integrated with other containerisation tools. Singularity was one of the other options we looked at, and we developed a package for the meta-virtualization layer in order to enable installing it using Yocto. Replacing Docker with Singularity is an option that will be further assessed in the future. We also deployed Docker Swarm to test if it can be used for managing clusters of devices. However, it was decided that not being able to control which device is performing the assigned tasks in swarm is not ideal for managing IoT devices, although it is an excellent tool for other applications, such as High Performance Computing.

The layer meta-cloud-services allows adding integration with popular cloud services, such as Azure, Amazon, and Google. Its capabilities have been tested during this research in the eﬀort of using Azure edge, Azure Servers, and the analytics tools for our implementation. This is still work in progress at the moment.

6.10 Face validation - results and discussion

In order to validate the architecture presented in this work, the system has been built and tested as an environmental monitoring device presented in the previous chapter, Chapter5. This section presents the results and conclusions from the software testing stage, summarised in Table 6.2.

6.10.1 Implementation details

The OS is a set of conﬁguration ﬁles, patches, and recipes using the Yocto Project. We used the Rocko branch of poky and made a recipe called meta-remote-management, which contains minimum packages require for running the environmental monitoring device described in this work.

The OTA capability has been built using the meta-updater [6] layer. The meta-updater layer requires a board-specific layer on top, with the purpose of providing a bootloader Chapter 6 Software architecture 83 that is able to use OSTree’s boot directory. It creates a fitImage which allows for pack- ing the device tree and kernel together, allowing for both to be updated over the air, which would not be possible to achieve without additional update scripts if the normal configuration was being used, as the devices tree is typically on the /boot partition and overlays are configured in config.txt. This created some difficulties for the RaspberryPi kernel, which is typically configured with device tree overlays and adding special dtparam commands in config.txt. To edit the device tree parameters, we had to look up the source of the overlays and manually apply them in the original device tree source file. This is achieved with a patch appended to the linux-raspberrypi recipe.

The meta-virtualization [1] layer provides the containerisation technology, in this example Docker. Docker is not the only option provided by this layer, it also enables installing singularity and LXC, for example.

We also built our own layer, meta-remote-management [10], to enable the use of the Cockpit project, as well as providing application-specific support such as configuration files, patches, and the standard configuration offered in a distribution.

To make our layer compatible with more devices we included patches and conﬁguration for the RaspberryPi in a separate layer, meta-remote-management-raspberrypi [11].

6.10.2 Experiments

Replacing the DHT22 sensor, as illustrated in the previous chapter, required relevant software modifications to be made using the Cockpit manager, OTA updates, and containers. The existing Docker application was modified and tested on a Raspberry Pi in the lab to ensure it was functioning as required before deployment. The relevant configuration files have also been built in the OS using the Yocto Project, and tested on a Raspberry Pi. The application was then updated on the Docker registry, and the new OS was also deployed on the server in the OSTree repository. The software was commissioned to the environmental monitoring device using Cockpit. The application image and the OS update sent only the difference between the versions running on the device and the newly modified ones. The architecture presented in this work allowed simple testing before deployment; the modular design has mechanisms that ensure the robustness of the system in case of failure. An application error does not affect other applications or the main OS. An OS update failure leads to automatic fallback to the previous OS working version. The read-only format of the sensitive directories also minimises vulnerability. The system logs and health are monitored remotely via the Cockpit manager. The example illustrates the maintainability, customisability, and extensibility of the architecture presented in this work.

At the software level, updating the OS and the running applications is traditionally done either physically, by changing the SD card, via full OS updates, or manually using the 84 Chapter 6 Software architecture package manager, which are limited by the available bandwidth and time-consuming. For example, on a generic embedded systems OS, such as Raspbian, each package update requires a full download of the package and required dependencies (if not up-to-date). Our experiments showed 50% smaller downloads than these traditional approaches, for example, updating the strace package to the latest version requires 932.16 kB download when using a traditional approach, but only 470.0 kB when using the implementation presented in this paper. This result agrees with other experiments in the literature [126]. Reduced update download leads to reduced costs due to bandwidth usage, saves time, and expands the possible deployment environments to more bandwidth constricted sites. A built-in computing board further minimises use cases and applications these devices can run. Devices that do not have delimitation between the host OS and applications are more prone to failure due to errors. The reference architecture presented in this paper is more eﬃcient as application errors are contained within the application container and do not aﬀect the rest of the system, while the OS has a read-only format for sensitive directories and it can be rolled back to previous versions. The system presented in this work allows testing and debugging before deployment and consistent images across multiple devices, increasing the robustness of the deployments.

Adding an additional sensor, such as the acceleration and orientation sensor addition presented in the previous chapter - Chapter5 - required a new application to be built, tested, and deployed over the air using the software stack developed in this work to test the extensibility of the system. The application was deployed in a container, which allowed testing and debugging without disrupting the existing applications or aﬀect the robustness of the device. Adding a new sensor to the existing device allowed using existing infrastructure for building and deploying new applications. The implications of this extension are: saving time and costs, reduced deployment complexity, reduced management complexity.

Increased hardware capabilities allow software stack developments that include new capabilities and better performance. As the software evolves, adds new features, ﬁxes, and security patches, older versions become obsolete. Newer hardware capabilities and performance increases enable more possibilities in software, which is reﬂected in newer software releases. As a result, old devices/hardware becomes out-dated, unable to run new software applications or to run them sub-optimally. This leads to the decommis- sioning of these devices.

An environmental monitoring device built ﬁve years ago on a non-modular architecture with a Raspberry Pi 1+ might still have fully functioning components (in reality components might break). However, the lack of software support, limited processing capabilities, and other hardware limitations would lead to device end-of-life. The reference architecture presented in this paper allows eﬃcient updating of the device components in order to increase its life span. For example, as new Raspberry Pi models become available, they can easily replace the older versions via the plug-and-play sensor board Chapter 6 Software architecture 85

Table 6.2: Summary of software face validation tests and results.

Design Test Result Requirements

Customisability Over the air update to add 50% smaller downloads and reliable new software package after rollback capabilities device deployment Extensibility Contained software appli- Robust testing and deployment of cation deployed over the new technology air to enable the use of new sensors Maintainability Cockpit device manager Fault detection and resource maintenance

Availability The software platform is World-wide availability built using open-source applications and tools. All the software developed as part of this research is available open-source. without the need for changing other electronic components. The software stack can be updated accordingly over the air to enable the hardware update, and new applications can be deployed remotely. The design of the system allows making these updates for less bandwidth, time, and cost. Using the Cockpit manager, multiple devices dispersed within the city can be updated remotely, to meet new requirements. These increase the life span of the devices and decrease management complexities. It also allows using existing infrastructure for the deployment of new applications, creating new opportunities for quick prototyping and rapid iterations of smart city applications.

In conclusion, the end-to-end system presented in this work proves that using the reference architecture developed in this work meets the design requirements - customisation, extension, and maintenance - allowing for developing devices with increased life span and reduced management complexity. The main speciﬁcations of the software stack developed as part of this research are:

• The system is open-source and does not depend on any proprietary technologies.

• The modules can be used independently from each other.

• The technology used for each module is non-restrictive and can be swapped for more suited one if needed.

• The applications and the OS have remotely and automatically updating capabilities. 86 Chapter 6 Software architecture

• The applications can be run independently from each other.

• The applications are built such that they can be run independently of the devices and main OS.

• The system needs to be resilient. i.e., handle faults like power failure, ﬁle corruption, unreliable network, etc.

• Applications can be developed and tested without necessarily using the target devices.

• The whole ﬂeet of devices can be easily managed and monitored remotely.

• Minimal OS that can be highly customised to adapt its capabilities or port it to new hardware.

6.10.3 Security and privacy

The security and privacy of this system was not the focus of this research project. This section aims to provide a list of suggestions for future work and clearly describe the security measures, limitations and issues of the project.

Software updates. The ability of the system to provide OTA updates is powerful and useful, but if not properly secure it can be dangerous. The current stack for software updates is a proof of concept, and it requires more security features for a large deployment.

The server which stores and serves the software updates patches to the clients must have strict controls of who can publish a new update. This can be achived simply by limiting access to the server (which it has been implicitly done), but in a larger organization more controls might be required, especially if this server is to be horizontally scaled.

The updates themselves must be cryptographically signed such that the client nodes can verify that the update has not been modiﬁed (maintain integrity) and that it comes from a trusted source. This has preliminary support and will be developed in the next stage.

The updates server must be using HTTPS (or other encrypted protocol) to serve the updates and, if required, provide appropraite access control such that only trusted clients can download software update patches. The latter can be implemented using machine- to-machine authentication, for instance using JWT tokens.

Node-to-server authentication. The network of devices that our system provides must not allow other devies to join in and pretend to be part of the fleet. This can be done by implementing a method of machine-to-machine authentication (ie. using JWT tokens as mentioned above, or SSH keys) but also it is required to have a way of provisioning authentication information the first time to each node. The initial provisioning Chapter 6 Software architecture 87 can happen at first boot by generating a set of SSH keys, printing out the public key fingerpring and asking the user to manually "trust" this fingerprint on the server. In the exemplar use case the MAC address of the clients are white listed for initial provisioning, instead of the public key fingerprint to allow to easily add and remove devices without user input and a screen.

Passwords and SSH access for large deployments. In the presented implementation, the password login for nodes is disabled by default and authorized SSH keys are pre-copied to each device at image build time. The keys can be updated via a system upgrade. This method provided the security features required without compromising simplicity. Manually keeping SSH keys up to date for a large deployment in a multi-user scenario is error prone. Another approach (after node-to-server authentication is setup) is to have the server maintain a list of authorized keys (one for each system user, and the server’s public key such that server’s Cockpit instance can see all nodes) that the clients periodically fetch. In this way, there is no need to use passwords for node access and no need to manually copy SSH keys to a large ﬂeet. This has the key advantage of allowing each system user to manage their own SSH keys (similar to GitHub).

VPN The presented deployment used VPN to ensure no outside access was granted to the network. All nodes were deployed under the VPN, as well as the server and all users who required access to the system. This has been used as an extra security measure.

Containerized applications. Applications can be deployed to the nodes in docker containers, which is a good solution to decouple the environment of the system from the application environment and allows for much greater ﬂexibility in application development. Containers also oﬀer a strict environment for running applications. The current deployment, however, uses priviledged containers to facilitate access to peripherals from application level. This voids to some extent the restricted envrionment and allows application to access much of the host system. It is not a security issue in our case, where the applications were our own development. On the other hand, a much stricter environment is needed in a context where applications are developed by third parties (ie. a city may employ other companies for application development for their smart city infrastructre). There is a need for an extra software layer, one that provides controlled access to peripherals for third party applications. This is described at length in the next section, where the issue of concurrent access to the same peripheral by many applications is also discussed.

6.10.4 Known issues and limitations

In this subsection, we discuss the known limitations of our proposed system and implementation at the software level. 88 Chapter 6 Software architecture

Yocto Project is a set of tools that allows creating Linux OS images for a variety of target devices. It enabled us to create our own OS that is conﬁgurable, extensible, modular,accessible and can be built for many devices. However, the suite of tools is somewhat complex and hard to navigate, having a steep learning curve. This results in users that intend to adapt our OS being forced to learn how to use many of the tools in the Yocto Project. Operations like building OS images, updates, and adding certain packages can be quickly learned by following instructions, but not all packages can be built using Yocto easily as they might not have already made recipes. Creating new Yocto recipes is similar to making new packages for diﬀerent Linux distributions, but the process is rather involved, especially if not already familiar with the Yocto project.

On the note of usability of the system, containerisation and developing applications to run inside Docker containers could be another challenge faced by researchers not already familiar with the technology. However, Docker has extensive documentation and tutorials that should make this process straightforward, and it can prove to be a worthwhile investment given the growing popularity of containerisation.

Automated testing is routinely used in software development, but currently, our system has no mechanism for eﬃciently testing the OS (and other functionality like the update system) other than manually performing checks on target devices. A step towards mitigating this is to add support for the QEMU emulator, which will allow for developing a toolkit for automated testing and rapid experimenting with the whole system, including the update system and containerised applications. An emulator built can also speed up development work on the OS itself and other modules but adds the complexity of supporting an extra target. Also, there is no guarantee that modules that work on the emulator will run as expected on other devices, which is the reason this was not included from the beginning. This limitation does not apply to the containerised applications, which can be eﬃciently designed to be testable without using target devices.

In our current setup, there is a lack of separation between containerised applications and hardware peripherals. Applications running in containers are given full access to the hardware peripherals (sensors, actuators), and this is the current way of using these devices. Two problems arise. First, two or more applications may access the same sensor or actuator at the same time potentially creating unknown outcomes which would be very diﬃcult to detect or debug (for example, two applications trying to rotate the same motor without knowledge of each other - at least one of them will get unexpected results). Second, there is no mechanism in place to guarantee strict access control to peripherals. This is best explained with an example: for a device that has a camera and a motion sensor, users might desire to grant access to an application to access the motion sensor but not the video stream. This can raise potential security and privacy issues: a vulnerability in any application can create a back door to the whole device. Chapter 6 Software architecture 89

Our current monitoring system, Cockpit, currently requires manually adding all the monitored devices via the user interface using their IP. All the devices must be accessible from the server that runs the user interface. Another limitation is that one needs to either type the username and password of these devices (same as used for SSH) or copy the public key of the server (web server machine) to the authorized_keys ﬁle of all target devices. Although not having a signiﬁcant impact on small deployments, the process can be prolonged when using many devices. This can be solved by implementing the SSH key management method described in the previous section and making sure that all the IPs of clients are added to the server’s Cockpit instance.

Currently, we use a simple HTTP server to make the OSTree repository available for target devices to access for system updates. This is easy to set up and sufficient for development purposes; however, it lacks a few features. There is no fine-grained access control, although this can be easily solved, for example, by password-protecting the server or running it behind a firewall. There is no separation between development branches of the OS and those that are meant to be deployed as updates, and there is no easy and documented method for pushing an update to the update server. The latter two issues can be solved by creating a new web service to replace the standard HTTP server for updates; it will have its own OSTree repository that it serves via HTTP for updates, but it will also support pushing new versions or branches of the OS to it, similar to how a git bare repository works.

It is currently difficult to make specific low-level configurations for some target devices like the Raspberry Pi. The Raspberry Pi device can be configured during the boot process by using Linux kernel overlays and special commands in the config.txt file from the boot partition (dtparam and dtoverlay). Adding or removing these dynamically configures the Linux kernel to load (or omit) specific overlays and settings. Our build does not use the overlay system and instead compiles the device tree and kernel image into a single fitImage. Configuring the Raspberry Pi device (and others that use similar systems) must be done by patching the Yocto recipe for the kernel (linux-raspberrypi for the Raspberry Pi). There is no simple workaround to address this issue, and we accept this as a known limitation.

We have focused our work on the end device software and hardware. The server-side counterparts to our system are basic and formed by many parts that are not integrated with each other. The cockpit web server simply needs to run on a Linux machine. The update server only needs to expose the OSTree repository, and a Docker registry is required for making (private) Docker applications available to download on the end devices. This simplistic approach has its beneﬁts, namely the fact that any of the subsystems can be used independently of each other and that it is easy to set up using standard tools. However, a more integrated solution can enable more enhanced device management features and data collection as well as oﬀer the possibility to add more layers of security and access control for administrators. Additionally, it can be released as an easy to set 90 Chapter 6 Software architecture up all-in-one solution that can save time for new users and make sure all modules are functional out of the box. Chapter 7

Conclusions

The work presented in this thesis has been generated in order to find the requirements for building IoT devices that are adaptable to new applications and technologies. Chapters3 and4 focus on finding these requirements and answering the research questions 1 and 2. The next chapters introduce new technology developed based on the design requirements - customisability, extesibility, maintainability and availability - testing its adherence to the requirements as well as its feasibility for in-field deployments.

This work gives an overview of the research done for designing, building, and testing an IoT device that is customisable, extensible, maintainable and available. The main research contributions of this work are:

• Reference architecture, introduced in the ﬁrst chapter of this thesis, Chapter1. The main advantage of this architecture is the end-to-end characteristic, which introduces both hardware and software modularity. This approach to designing and building IoT devices is not explored enough in literature and provides more ﬂexibility around building durable IoT devices that can withstand the high rate of technological advances in the IoT area and can be sustainably maintained.

• Design requirements, identiﬁed in Chapters3 and4 for designing and building IoT devices with an increased life span and minimal added management complexity for adding new technologies and extending deployed infrastructures: accessibility, customisability, extensibility, and maintainability.

• Method - presented in Chapter5 and Chapter6 - which introduce open, modular sensor board and software platform respectively. These have been used for implementing the reference architecture as an environmental monitoring use case. The implementation is an example, and each of the technologies and modules used are not final, where each of them can be modified and adapted after deployment when improved, better-suited, or more cost-effective solutions become available.

91 92 Chapter 7 Conclusions

Increasing the lifespan of IoT devices requires modular architectures that allow updating after deployment. The next-generation IoT device allows swapping, adding and removing sensors (or other peripherals)

During this research, we have developed and built a hardware extension board, PiSEB, that can be used with oﬀ the shelf sensors, actuators, computing boards, and microcontrollers. This board has been implemented and tested using a wide range of sensors required in a real-life scenario, environmental monitoring, proving its adherence to the design requirements. Face validation tests include adding and replacing sensors in order to expand the device capabilities for sensing environmental factors, as well as maintaining the device. The sensors used for the example presented in this work were chosen based on availability, while manufacturer and communication protocols did not impose any limitations on the sensors selection process.

In order to provide a complete implementation of the reference architecture and enable the type of high-level ﬂexibility required for the next generation IoT device, a software stack adhering to the design requirements has also been developed. It consists of three core modules: minimal OS built using Yocto, incremental OTA updates powered by OSTree, and system monitoring using Cockpit. The modules are interchangeable and not depending on each other, and the OS is highly customizable with Yocto. This has been successfully tested with Raspberry Pi 2, Raspberry Pi 3, Raspberry Pi 3 Model B+, the Up-Board, and Odroid C+. The software stack has been implemented and tested as part of the real-life environmental monitoring example. The tests have proven that the software stack enhances the device architecture by enabling hardware and software updates for sustainably extending the life of IoT devices. The resulting device has the necessary capabilities for allowing further expansion and serves as a working example and a starting point for new projects.

One of the most signiﬁcant contributions of this work is the end-to-end modular, open system reference architecture, which, unlike other related work, includes both hardware and software levels. Modularity at both the hardware and software levels increases granularity and oﬀers a complete solution for optimally meeting the design requirements to increasing device lifespan while reducing management complexities. Libellium and Balena are using similar architectures at hardware and software levels, respectively, but their work is not extensible, customisable or end-to-end (both hardware and software).

A significant advantage of the system presented in this work is the open-source aspect, as well as not locking a potential user to specific technologies. Due to this, the implementation and integration of the architecture presented here to specific applications are less complex and time-consuming. This also allows collaborations between different parties and eases the re-use of deployed infrastructures. Chapter 7 Conclusions 93

Another main advantage is modularity. Each module is of the system is independent, which, unlike other architectures, allows the users to chose which modules are necessary and what technology is a better ﬁt for their use-case. This also enables further development after deployment, such as adding or updating components, allowing new technologies to be built upon existing infrastructures, as well as maintaining optimal operations and continuous adherence to the state-of-the-art. This results in an increased device life span and a signiﬁcant drop in deployed devices.

The system architecture presented in this work is generic, which is very different from other ones in the literature, which limits the user to a specific use-case. This enables collaborations between different parties, but also device re-purposability during operation.

The architecture presented here details both software and hardware requirements for developing robust, next-generation IoT systems, which solves scalability problems, reduces devices management complexities and e-waste as well as enabling the next generation IoT innovations.

At the software level, the main disadvantage is given by the complexity of running the Yocto Project. The sensor board designed and built for this research, PiSEB, is generic but has a limited number of sockets and supports a limited number of interfaces. The hardware board presented here is an exemplar built for proof of concept. The main components of this work are open-source to allow uptake in the IoT community.

In this thesis we have researched and developed an open modular architecture for the hardware and software required for Internet of Things sensor systems. This opens the door for new robust, resilient, and cost eﬀective ways to monitor and study the world in which we live.

Chapter 8

Future work

The next steps are to continue iterating on the IoT generic device, build, test, and deploy it at scale. The focus will be on covering some of the known limitations, testing the system with a deployment of 100+ sensors around the city of Southampton. As part of this deployment, extra tools will be developed to help manage the whole ﬂeet, including server-side software for device management and data collection, but also software development tools for creating OS updates faster and aiding the development and testing of containerised applications.

The immediate next steps are:

• Developing a deployed device meta-data storage on the server-side. Each device has a unique identifier, but allowing filtering, searching, and deploying updates and applications to groups of devices filtered by meta-data stored about each device would ease the management of large fleets. Such metadata can include the geolocation of the deployed node, list of sensors available, date of last hardware maintenance or check, os versions and other application-specific data points (for example, whether the device is in a typically crowded location or a quiet residential area, or whether there are other restrictions in place due to local laws and regula- tions and deployment spot). This can be implemented as a plugin to Cockpit.

• Stress testing the devices in simulated constrained environments is also a step we are planning to take in the future. This includes controlled random power and network outages in critical moments of the system operation: during reboots, system updates, application deployments, etc. Finding weak spots in our software and hardware solutions will enable us to ﬁnd mitigating solutions.

• Using Long Range Wide Area Network (LoRaWAN) for sending and receiving data because it has low power and wide range, which makes it a very attractive technology for IoT devices, especially those deployed in remote areas where other

95 96 Chapter 8 Future work

networks might be out of reach or too expensive to setup. Deploying updates, applications, and real-time device management will not be available for devices to connect via LoRaWAN, but developing a solution that allows managing these devices with intermittent high bandwidth networks is feasible.

• Testing the devices with many sensor conﬁgurations to ﬁnd whether there are incompatibilities or if the devices anyhow become unstable due to too many peripherals connected (e.g., CPU load too high, power issues, bandwidth issues via the peripheral interfaces, network bandwidth issues or data storage limitations), and how to mitigate for these situations.

• Using the system in a real research project which will allow us to write compre- hensive documentation for new users, tutor other researchers into how to use our systems, and learn which areas need to be improved in terms of accessibility and ease of use.

In this architecture, data processing was considered to be addressed at application level. However there are data-related challenges that can solved at architecture level via aux- iliary services. For instance

• Persistent local data storage to account for possible network connection loss. This can be achieved by creating a data partition with strict write accessibility, where only a speciﬁc application or user can write data. This way, each application has a dedicated writeable location.

• A broker has to be used in order to ensure that there is no data loss due to poor system malfunction or loss of network connectivity. This is a common problem for most applications and can be provided as a service on the client nodes, as opposed to allowing each application to handle this separately.

• Data has to be sent and stored securely, which can be achieved by using encrypted data transmission protocols and encrypting data at rest, but also by ensuring applications don’t have access to each other’s data.

• Part of this work explored existing services that oﬀer data storage and processing. Their compatibility with the software stack presented in this work has been tested, but more work is required to ensure good functioning at large scale. As a result of these tests, Microsoft Azure, Amazon Web Services and Google Cloud Platform will be considered for this step.

• A generic solution for streaming data from sensors to servers can be provided to aid and speed up development of applications but also ensure best practices for security and privacy are followed. Chapter 8 Future work 97

This future work will be done as part of the EPSRC Doctoral Prize program that I will start after ﬁnishing my Ph.D. candidature.

Appendix A

PiSEB v1.0 Eagle Schematics

This appendix includes the Eagle Schematics of the ﬁrst version of the PiSEB board.

99 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 1 9

/ U s e r s 1 1 / m J 1 i h 0 MICRO USB , a J

3 J1 e J6, HDMI T , l H C a E A a R M p

N J7, A/V E e E R J t T 4 A r

P MICRO SD (bottom) , o

P D 1 a 2 2 I S i _ _ e P S S - L I I G c G A r L G Y p p i a a O s s s P

1 1 P t I 0 R 0 R O e R R Y 1 4 7 1 1 a _

9 J9 R / _ + D S F 3

J DO NOT USE these pins for anything other T p p o R V a a 1 _ than attaching an I2C ID EEPROM. Leave s s s u

1 E 3 c 1 1 p unconnected if ID EEPROM not reqE uired. P P

, S S G S S 0 E 2 2 u

N $ $ 2 P P C D + P 4 4 m

These pins are reserved for ID EEPROM I S S S S X i i o o 3 D I I L A 1 2 I

_ _

Raspberry Pi 2 0 0 P P P P O

V _ U _ G _ e G G At boot time this I2C interface will be s I I I I u 3 4 3 S 3 _ _ _ _ p S

interrogated to look for an EEPROM P n P P

R R + V 0 V S M M G D

B that identifies the attached board and I U U I I 3 t 3 O 3 C O O P I O

s allows automagic setup of the GPIOs V N N S 1 L I

(and optionally, Linux drivers). 2 1 / S _ _ 3 O

GND GND O GND 3 K p 1 2 I 3 i

*ID_SD and ID_SP C PIP NS: P P P P P P P P P P P P P i i i i i i i i i i i i i i i i i i i i s s s - o o o o o o o o o o o o o o o o o o o o P P P P P u u u $ $ $ $ $ $ $ $ $ $ $ $ $ $

$ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p p p s

$ $ $ $ $ 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1 0 0 0 e 9 7 5 3 1 9 7 5 3 1 9 7 5 3 1 9 7 5 3 1 b / G G G G G G I G G G G 3 G G G G G G G 3 G J D v J V V 8 N P P P P P N P P P P P P N P P P _ P 1 3 3 1 I I I I I I I I I I I I I I D D D S O O O O O O O O O O O O O O 2 I O - D , 2 1 1 6 5 1 9 1 2 2 1 4 3 2 0

* 1

6 9 3 0 2 7 7 2 E / X v x

p U G G G G G G G G G G 1 I a G G D S P P P P P P P P P P . n _ P P G G G G G 0 I I I I I I I I I I B O O O O O O O O O O s S I I N N N N N O O . i 5 5 C 2 2 1 1 2 2 2 1 1 1 o s D D D D D V V 7 8 1 0 6 2 5 4 3 8 5 4 * n c h P P P P P P P P P P P P P P P P P P P P

$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ ( i i i i i i i i i i i i i i i i i i i i 4 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1 8 6 4 2 o o o o o o o o o o o o o o o o o o o o S

0 8 6 4 2 0 8 6 4 2 0 8 6 4 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 3 h s u e p

G G G G I S S G G S G P P P 0 D e P P P I I I P P P P P P P _ _ _ _ t I I I I I I I I I I T T 5 S : 0 0 _ O O O O O O O

V T T _ _ G C 1 2 2 1 1 2 2 1 L L C C GND P 1 0 6 2 5 4 8 / _ _ S S 8 _ _ _ _ _ I _ R T O 1 0 F F F F F F ) X X 4 R R R R R R D D s s s s E E E E E E u u u u p p p p

E E E E E E 0 0 0 0

GND GND GND GND t

32.768khZ@6paPs 1f 2 1 pas 1 h c e r 4 4 y

G S i o Q1 o s

L O P 0 e n N t sup 0 D P F a e l n y D X X G - l X I o e e

t C13 2 1 b

N d T c c r sup 0pas 1 pas 1 5 w _ _ r a a A

a o V 1 D G V

+3V3 d e R R c t 2 l - L t l 100nf C11 o 2 k N

T T pas 1sup 0 sup 0pas 1 A 0 w c 0 e s r D C C 1 o d y

s a r S S S S S S s V 6

d 100nf d

B n h h n + P P P P P P 1 e r A t o o o e t

T p p 7

I I I I I I t a a _ _ _ _ 0 0 l u 1 t s h s s 8 d

1 1 s G G G G _ _ + l h i

e d s 1 C 1 C h : 1 C C a

0 0 P P P P r

S 3 1 E * i e 0 b p

o v p p S S 2 T o

I I I I 0 C f f s 1 e e e in 0 O O O O X X R 1 0 n P e 0

r L s s 4 3 2 1

m 2 1 T

1 0 s _ G n y o

_ _ +3V3 C 7 0 e e 3 x m e c p p p p R R N 0 a a e sup 0 sup 0 a w n _ V i i i i i i k e s s n n n n n n s r e

0 T T e

D 1 1 a B e 0 0 0 0 0 0 0 0 d 3 p p t n n w w d C C i i i i n t 1 1 1 1 r

n n n n A c c p r r s

t i 0 0 0 0 0 0 0 0 8 3 2 1 3 4 5 6 t p p p c e T

l w w w G i i y 1 1 1 1 1 1 b n n

+3V3 1 a s r r r T

0 0 0 0 0 1 9 4 0 7 6 5 2

e l N t

sup 0 sup 0 p S i t n a o D w 4 2 1 3 8 g G 2 2 1 1 2 1 V w e

A A A A ~ ~ C N e e e E E N N V A A A S V 1 0 1 0 R C D x r n n P S 2 1 0 C D C C e p U

V X X V V S L D d _ 1 e 7 S 2 1 B C M 2 1

6 M r 4 g S A C i U 5 5

U d 0 e C i T a H T v C I m 2 G n 1 e P C P d e n N sup 0 2

T n e

7 4 D t 3 C t M h 1 * 9 0 a 2 2 2 2 1 1 1 1 R M S 0 e S

~ ~ ~ ~ ~ ~ ~ ~ 3 l 4 l p G G G G G G G G E G G G G G G G G D

F 1 C y Y Y Y Y Y Y Y Y I 9 P I r 1 S i N S N P P P P P P P P A P P P P P P P P P n 3 2 1 0 3 2 1 0 L 7 D i D 2 E T A A A A A A A A B B B B B B B B T

s - c A A B - T 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 E u a I / n / S S 5 6 7 9 1 1 1 7 6 5 4

A b 1 N 0 2 O d e x 8 7 6 5 4 3 2 1 2 2 2 2 2 2 2 2 2 1 1 1 p p p o o o o o o o o d

8 7 6 5 4 3 2 1 0 9 8 3 a a a u u u u u u u u s s s s t t t t t t t t e

0 0 0 0 0 0 0 0 0 0 0 w i i i i i i i i i i i i i i i i o o o i o o o o o o o o o o o o o o o o o d u u u

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t t t i

0 0 0 G G t n c e P P h w e I I O O d

G R R R R R R R R

+3V3 h ? C2 1 1 P P P P P P P P e N

spuaps 01 sup 0pas 1 S S S 3 2

a I I I I I I I I D W ______D C D 100nf d C C C C C C C C A L A e h p p p p p p p p p p p p p p p p S S S S S S S S _ r a a a a a a a a a a a a a a a a a _ _ s s s s s s s s s s s s s s s s

J t w 8 7 6 5 4 3 2 1 3 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 p ' 5 a s V V V 1 1 1 1 1 1 1 s i t

1 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 3 h t 3 3 1 R h

0 2 f e K r A 1

6 b 1 d e p / 6 6 a 1 -

d +3V3

2 0 t r r t . W sup 0 p 5 e e p 4 i a r

s s g y

1 s

l p p p p p p p p p p p p p p p p 1 i a a a a a a a a a a a a a a a a i f o s s s s s s s s s s s s s s s s 1 e

J 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

6 0

a 1 1 1 1 1 1 l 1 i 1 n 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 k 1 d e 1

? 1 5 1 6 V p , -

2 3 . 5 V 4 3

a n F d D

G P R N D H E i T

G E & N 2 sup 0 G p w D P i i i n n n P r

0 0 0 0 I 2 I _ 7 7 3

O R 5 + 4 3 2 1 V R18

4 pas 1 pas 1 I V 3 D

p SCL_3V3 3 a V s

1 10K 3 P G A A A R16 B U pas 1 pas 1 2 1 0 N R i 8 1 C 0

D +3V3 C I 2 g 0

i 10K o 1 4 n sup 0

0 9 V f S S G G i p o W D G C a D

G G G G G G G S F C 0 s 3 N

6 sup 0 M C i R A P 1

L P P P P P P P 2 2 D S F D P t - I I I I I I I 6 M 1 P

3 R19 O O O O O O O 0

2 pas 1 pas 1 P D

p p p SDA_3V3 a 0 h 2 2 2 2 1 1 1 w a w 1 i E o 6 s r r 5 6 7 8 2 a

5 4 1 0 9 8 6 0 0 0 0 R 10K 0 s ______5 i 6 o I u

F F F F F F F R 4 3 2 1 i i i p 0 o o n l 1 0 w E

5 i 0 0 0 O R R R R R R R o r S .

0 8 0 F 0 E E E E E E E T U I I K D D S l E E E E E E E E $ F

P G N D V _ _ p M 7 l s S D 2 v . A S S N u p p p p p p p p p p p p p p p p C a a a a a a a a a a a a a a a a G T P u D l D D C 1 5 s s s s s s s s s s s s s s s s h . l

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 - R N 1 u / sup 0 . H e 1 1 1 1 1 1 1 0 0 0 p D 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 p U e

7 a T p s in 0 r

M e 1 P / t O 1 G 1 R 2 : s 6 - 6 K T 3 i S 0 N p s

in 0 sup 0 6 s P - E t 2 1 D o i i o o 1 7 . N

5 M 1 1 r 9 p p p p p p p p p p p p p p p p 8 8 4 s a a a a a a a a a a a a a a a a / S s s s s s s s s s s s s s s s s

J J 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 p 2 f O 1 8 a o 1 1 1 1 1 1 s 1 1 0

1 r R 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0

R37 i - 2

3 pas 1 pas 1 D c 2 1 1 3 7 H 6 2 3.9K V p p T - 3 - 2 2 2 . . 5 5 2 4 4 R38 pas 1 pas 1 3.9K D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

P 1 L L L L 2 D R15 O O O 3 _ LOPY_RST_EpasN 1 pas 1 o S P P P :

1 I Y Y Y o C p w 0R G 9 _ _ _ p o e y R43 a R T 3 s n

pas 1 pas 1

c w 0 V

X n X P i / o o a e 3 D

Q U D 0

100K 1/10W G n c m G 3 0 0 t t S F s

S D N R 7 f sup 0 pas 0 pas 0 M B

o e 9 y S D U D S r S L r 1 +5V T l 1 2 n n n s O A o R44 i o c c c 3 0

1 pas 1 pas 1 sup 0 1

i 0 0 0 0 w P / 8

o 6 P

R m W 0 R 2 - Y 5

100K 1/10W i l U - o

e 7 T S F 0

& _ 0 p i - 0 v 7 a M h F P s P S 8 0 e

D 0 F a 2 1 l 1

L L L R 2 b 2 P Q L U e G A 0 O O O O o 3

S 6 1 6 c l P R R R o T R a

2 +5V S D o

pas 0 pas 0 Y B t 5 i A A A o _ n l a pwr 0 sup 0 S L 0

o 0 _ _ _ S n 0 S 5V O a R M M C p S 1 e I G d p p p p p G F L 3 P I O a a a a a c e G S 8 e s s s s s K N

t pwsru 0p 0

Y S W 0 0 0 0 0 O e t N r sup 0

D GND i I _ r o - d 7

D G i i o 0 3 o o J T

F 1 1 t S V N a sup 0 o pwr 0 B LOPY_3V3 S F T 3

8 M

D 3V3 J L L L L L P P P P P P P P P P P P P 2 1 i

R45 P t 1 3 -

e pas 1 pas 1 h O O O O O P P P P P P P D 2 2 2 2 1 1 1 1 1 1 1 1 1 1 X p e 1 9 8 4 3 2 1 0 3 2 1 0 9 8 7 6 5 4 3 2 0 1 P P P P P - H 2

100K 1/10W Y Y Y Y Y c p y P 0 o a + - 6 s _ _ _ _ _ r 0 2 1

c i G 5 0 R

U U U U U i 5 b 2 5 V i s o o N A A A A A sup 0 p Q 0 -

e G 0 - P t R R R R R o 0 D m 2 7 c i

o +5V e S .

T T T T T I L a 0 5

R46 i i i i i i i i i i i i i i i i i i i i i o o o o o n n n n n n o o o o o o o o o o S D F pas 0 papsa 1s 0 pas 1 sup 0 N 4 0 0 0 0 0 B L L a u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

- - - - - S - S F U O O s 5 4 3 2 1 / R t 8 S 100K 1/10W M e D P P 0 1 o O D A

p 3 l a Y Y t 1 8 o s h U 2

R W 0 _ _ o e 0 c N R T - 6

7 T P Q L L L L L L L L L L P L L L L L L L L L L R P G 2 2 u D X - X 8 O O O O O O O O O O O O O O O O O O O O F 5 i I o i 1 - m D _

D 0 a P S D d P P P P P P P P P P P P P P P P P P P P

pas 0 pas 0 0 P C 1 1 S o A Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y J e W p p p p p F e 2 y a a a a a D G ______s s s s s 3 n s

R 0 0 0 0 0 0 P P P P P P P P P C M M S S C R T P T R d N

sup 0 5 t w p _ X X 2 2 2 2 1 1 1 1 1 C D 2 S S X X a D I O s J s S C 3 2 1 0 9 8 7 6 5 e D D

2 L A 1 D D 1 S / S O i 0 R T / p 1 0 r e 1 0 T C R I d L L L L L 8 R i - O O O O O L L

L - p X t L a O O h K P P P P P s s H

1 i r Y Y Y Y Y P P n e 0 R - _ _ _ _ _ g R 0 Y Y 1 b p U U U U U

2 a s 5 _ _ s A A A A A /

- 1 i i M 3 t o o v P p R R R R R o

1 1 V 1 T T T T T I I P

S N G 3 1 1 1 1 1 J P 2 1 p I - 4 a O _ ------P I s 0 5 4 3 2 1 R i

_ T 1 I O T / O T n v T L

U 2 1 o 1 L _ N 2 n _ T . p

s D 0 R - X b 2 . - o X . D 5 P s o 4 D A t c ? D t h e

s ( I U s t S Z H M S

e 3 3 X i s i r c h B o 6 h d r s 2 o 3 i e e -

U B R l - e S S d 5 B P H t P V r A : I e G B

E I a 2 N U D L L L + L

D I l G D D D S l O O O 5 + / y - 8 V

P P P c P ) Y Y Y o I n _ _ _ O n s s i i i s S S 3 o o o u u u

e 0 0 0 p p p V C D

0 0 0 i c o 3 o

U U L A 0 t e L / n S S C d L S F i + o B B 8

M L L L L L L L L L

O L 0 5 t 3 b _ _ O O O O O O O O O D o K V P o S F 1 D D o

P P P P P P P P P G 7 2 M Y i o P M 6 0 o

Y Y Y Y Y Y Y Y Y D 0 _ N 6 1 R ______3 t D 2 P G S F , 5 i P P P P P P P P P V o 0 8 M

? 0 6 N 2 1 1 1 1 1 2 2 2 2 t 3 sup 0 0 D R h S 5 6 7 8 9 0 1 2 3 D 1 5 i o F 2 0

e i 0 o 0 y 0

0 p 6 S y a R s F

S F

1 5

C9 i o a 5 pas 1 pas 1 M 0

9 0 D r p p p p p S a a a a a 3 L G 1 10nf e I s s s s s F 3 1 2

4 4 0 0 0 0 0 N 0 0

sup 0 R 2 6 n D R - J 1 5 o i S p p p p p p p p p p p p p p p p o 5 a a a a a a a a a a a a a a a a G 0

0 0 s s s s s s s s s s s s s s s s T 0 t

J L L L L L 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 p C N S

7 - sup 0 a M O O O O O 1 1 1 1 1 1 s d 1 X F

D 1 A 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 P P P P P H o Y Y Y Y Y - _ _ _ _ _ i 0 1 n C15 I I I I I 6

pas 1 pas 1 2 2 2 2 2 5 p g C C C C C - - P 2 - - - - -

100nf . 5 4 3 2 1 5 I a N 4 G p p p p p p p p p p p p p p p p n a a a a a a a a a a a a a a a a - T s s s s s s s s s s s s s s s s N sup 0 in 0 R

J y 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 P 9 D O 1 1 1 1 1 1 1 5

1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 t U o N g 1 D

6 pas 0 pas 0 g p - + - - P 2 l G i . A 5 n C16 N

4 passu 1p 0 pas 1 4.7uf C17 D g D F

, 100nf

T s D o I U U L L L L L + 1

O O O O O 5 S S _ c V 3 P P P P P B B o V Y Y Y Y Y _ _ 5 5 n 3 D D _ _ _ _ _ L n S M M C 3 M P i o V C e S

I O 0 S 3 L 1 c S O o L S F / t C I 7 M i i i i i i i i i n n n n n n n n n e 5

D L i 0 0 0 0 0 0 0 0 0 o 2 1 1 1 2 2 1 2

d 1 0 K 4 5 6 5 7 8 7 9 0 2 P o L

0 U S F O p 6 7 M 6 R P 4 G U U 3 O O R V V 2 D 5 i o V Y C C P 0

S S E 1 N S S 0

y 0 2 3 B B S C C _ a C C D S 0 O F D D E U I 6 O I F n T O U R T M P 2 S 5 i T

d 3 o y 0

B 2 0 0

R F _ S m L p p p p p p p 5 F C C C C C - a a a a a a a G S s s s s s s s V B B B B B T

i 0 0 0 0 0 0 0 S G G G D N D R D s C T R U U U U U E sup 0 O C N N N T X S X T D T S T S S S S S o P J R R D D R D D D D S S T 2 4 3 2 1 0 S I

8 d T L L L L L L L - O O O O O O O i D 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 X r 1 1 8 6 2 4 3 2 3 0 P P P P P P P e H i i i i i i i i i i i i i i i i i Y Y Y Y Y Y Y n n n n n n n n n n n n n n n n n

- c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p ______0 a S S S S S S S s t 7

1 I l P P P P P P P y 0 R - P I I I I I I I R G 1 ------

7 6 5 4 3 2 1 3 I t N N

6 sup 0 6 o p a D - s

1 G 0 R O p R a 1 s P U 4

1 N I O D - p

P a L L p s A

1 O O i D n P P s Y Y _ _ T R X X D D u 0 0 S P D

y BLUE-0603 330R pas 0 papsa 1s 0 pas 1 c 7 D2 R1 GND 7 o L L L L L s u O O O O O p

0 P P P P P Y Y Y Y Y m

GREEN-0603 _ _ _ _ _

330R M S 3 M C V C pas 0 papsa 1s 0 pas 1 S I O S 3 L 2 S O

D3 R3 / C I L K i i i i i i i i i o o o o o o o o o

0 0 0 0 0 0 0 0 0 9 8 7 6 5 4 3 2 1 J 2 C D D V S V D C D S S C D 2 v D A O I S A M T T S L D N 1 5 h A A K I C / . 1 2 e 0 R 0 O e 7 S / t D 2 : - 9 0 P 1 2 9 8 8 / G

8 io 0 io 0

G G1 G4 2 G1 G4 N N 0 suipo 00 G2 G3 io 0 sup 0 D

D G2 G3 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : C 1 D - + N J 9 1

/ U D C s - e 0 4 r 4 i i i o o o - s G

0 0 0 A 1 1 / N sup 0 m +24V_UNREG_IN D i h p a a s e 0 l a 3 F a 0 1

U11 7 p 0 e 1 0 t r 0 5 o

pas 0 1 0 V R20 a pas 1 pas 1 ANODE 5 G 3 _ p i 5 N a

e sup 0pas 0 pas 0 15K 1/10W D s

nc 0 pas 0 D - + 2 3 0 I -

NC CATHODE P c T _

r in 0 G o

10uf C4 P P i T C18 v s p 8 N sup 0 pas 1 ipna 0s 1 P a e P s t

T D N r 0 p e 1 v a 2 D C i 100nf n e s 6 8 o

1 a 0 0 BZX84C30 e _ V l t - / d 4 5 a 2 1 D A s A g

_ e g o 0

p o p a c 3 s o r

A V 0 2 2 u 1 o d D I m

p +24V N 0 t m a e g J s y sup 0

/ c 0 r G

o D e l t i i N u b o n pas 0 pas 0 L D n r i i n o o U a

d 0 0 t ? r C U s $

y p C 4 1 $ /

l pwr 0 TAB D p a TAB 0 3 n M 6 i D U - e D s C $ I

I I G C f N N & 5 e o - O V D - + 2 r b

O C t 9 e / U - 3 v r S T D m 0 1 G T a 0 - E N sup 0 l 0

P D i s 3 / - C s v D u O 1 O O o e u U t U

s . W 0 T 0 T T + N in 0 - . P s - 1 L c M h 2

5 ( G i i o o 9 S

0 0 N 3 3 pas 0 sup 0 pas 0 6 h D - + e e 10uf C10 +5V T t sup 0 in 0 T : P

P 4 3 5 4 V /

8 & 3

5 ) T P 1

s h o u l d

b e

c l o s e

t o g e t h e r 4 4

G MK-12C02 G1.5 SW3 N sup 0 D P io 0 io 0 P C I O _ M P T L A B

i in 0 O P W

9 io 0 io 0 P G R A C B Y P O N sup 0 _ _ i i i o o o C M D

0 0 0 3 T V R 3 o R40 L pas 1 pas 1

w 100K 1/10W p a s

0 Q

G TP12 4 e R39 pas 0 S D pas 0 pas 1 pas 1 B i n S

0 5 5

S 100K 1/10W r 1

p +5V 3 a 8 s

sup 0

W 0 - C 7 Q G - 2 F

pas 0 S D pas 0 S S M o T 3

in 0 J P p 3 a 2 s 1 n

8 0 0 R , L

Q5 DSSM3J32F 8R,LF t pas 0 G r S o P p a I s

_ T in 0 0 5 P l V 1 1 P 6 6

+3V3 i

sup 0 T in 0 f G C12 P i p p 2 N pas 1sup 0 pas 1 a a s s

D l 1 100nf 1 t 3 L 3 L e 3 3 3 2 0 0 R R - - 1 1 r 5 5 0 0 0 0 GNDA p p a a M M C14 s s

sup 0pas 1 pa s 1 1 1 A A f in 0 T

100nf P o 3 + r 3 V

3 _ 3 S P M O 7 7 V O S T H 3 U S 2 v 1 5 h / . e 0 0 e 7 / t 2 : 0 1 3 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 1 9

/ U s e r s 1 1 / m i h a e l a a p e t r o a i e - c r i s t e a / D o c 2 2 u m e n t s / p i - s e b / v 1 - 0 / v 1 . 0 . s c h

( S 3 3 h S e C e GNDA L t

pas 0 pas 0 _ pas 0 sup 0 pas 0 1 S : GNDA +3V3_SMOOTH

3 1 - + - + C

4 sup 0 sup 0 A A A A A A A A 1 A A A A A A A A V 0 +3V3_SMOOTH L 1 1 / C7 C6 D D D D D D D D D D D D D D D D 3

_ pas 1 psausp 10 pas 1 pas 1 8 0

0 10uf C5 10uf C8 C C C C C C C C C C C C C C C C 3 1 0 ) V 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 1

100nf 0 100nf 1 + + - + - + - + - + - + - + - + - + 0 3

GNDA 3 3 0 V V sup 0 p p p p w w w w i i i i i i i i i i i i i i i i i i i i i i

n n n n n n n n n n n GNDA n n n n n n n n n n n 3 3 r r r r

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

_ sup 0 _ 1 1 1 1 1 1 1 1 1 1 S S 1 1 5 9 8 4 3 2 1 6 5 9 8 4 3 2 1 6 0 4 3 2 0 4 3 2 M M O O O O V A A S C C C C C C C C V V A A S C C C C C C C C V T T S D D C D S D D C D H H H H H H H H H H H H H H H H H H S S R R L D R R L D 4 4 3 3 2 2 1 1 4 4 3 3 2 2 1 1 - + - + - + - + - + - + - + - + 1 0 1 0 M M U U C C $ $ 2 1 P P 3 3 4 4 2 2 4 4 S S 4 4 D D - - E E A A / / S S L L 7 7 i i o o

0 0 S S D D A A _ _ 3 3 V V 3 3 5 5 6 6 A D 7 7 C S 2 v 1 5 h / . e 0 0 e 7 / t 2 : 0 1 4 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 1

9 BLUE-0603

/ R35 pas 0 pasp a0s 1 pas 1 U 5V_USB_HUB L s D11 1K E e D r _ s 1 1 G / m N RED-0603 D i h R22 pas 0 ppaass 01 pas 1 LOPY_3V3 a

e D14100R l a a RED-0603 p

e R11 pas 0 pasp a0s 1 paLs 1OPY_USB_5V t r

o D10 1K a i e - c RED-0603 r +24V i R5 s pas 0 pasp a0s 1 pas 1 sup 0 t G e D4 1K N sup 0 a D / C i i i D o o o

O 0 0 0 RED-0603 M o A B +5V c io 0 io 0 R6 pas 0 pasp a0s 1 pas 1 sup 0 2 2 u A C B m O D5 220R M e io 0 io 0 n

t RED-0603 s MK-12C02 G1.5 SW4 R7 / pas 0 pasp a0s 1 pas 1 p 5V35 i D6 330R - s e b / v 1 - 0 / v 1 . 0 RED-0603

. +3V3 s R9 pas 0 ppaass 01 pas 1 sup 0 c h D8100R

(

S RED-0603 3 3 h R10 pas 0 ppaass 01 pas 1 e +3V3_SMOOTH e D9100R t :

/ RED-0603 8 R21 ) pas 0 ppaass 01 paPs 1I_5V D13220R

RED-0603 R4 pas 0 ppaass 01 paPs 1I_PWR_CTRL D22220R 4 4 5 5 6 6 L E 7 7 D s M H M H M H M H M H M H 6 5 4 3 2 1 O O O O O O U U U U U U N N N N N N S 2 v T T T T T T 1 5 h ------H H H H H H / . e 0 0 O O O O O O e 7 L L L L L L / t E E E E E E 2 : 3 3 3 3 3 3 0 ...... 0 0 0 0 0 0 1 5 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : R T + P R T + P P P + P 1 R R + P 3 3 3 X X I I I I I X X _ _ _ _ _ 3 9 V V V I S S D D D D _ 5 5 T T 5 R R V 3 3 3 2 2

2 1 5 R R + P V V V 2 1 T T i o

3 3 3

V 3 i i 0 / I L L o o S S _ 2 2

U i 0 0 V o _ _ 4 4

5 S F _ _ 0 R T 3 8 8 5 M S F S F V s 3 3 i P P o 0 X 5 4 5 5

M M X S F D 0 _ _ e 2 8 5 M S S S R + P S S S R + P S S S R + P _ _ D D D 1 D R T 4 2 S F S S S R + r D B A 1 1 3 3 3 P P P I P P P I P P P I P P P X 0 X 4 _ _ _ 2 2 s M P 1 3 V V V P P P P 6 I I I I I I I I I 6 0 0 I I I D 1 1 2 5 5 5 I I D D ______R V _ _ _ I / 6 6 3 3 3 I I I 0 I _ V V V m 1 _ _ _ i R R 5 S M M S M M S M M _ i C C C o 6 o 3 2

i i i i 0 R 5 5 S M M i i 0 C o o o o o o C C C 0 S S S 0 I O I O I O

0 0

V i 0 0 0 0 5 i 0 0 o i 6 S S S o S C S 0 0 I O

U R L L L S F 0 h 4 3 2 i i i 0 R 0 o o o S S S S F S S O O O 0 2

M L S F S F S F S F K K K 1 0 0 0 5 i S o F F S a 4 I I I O 5 4 5 4 M M M M S F 0

K D 0 F 3 9 1 I 0 5 M S F S F S F D D D D 1 e S 5 4 2 2 2 M M M D 1 1 1 1 F 7 8 0 l 2 2 2 2 D D D 1 A S a 6 0 0 0 0 2 1 1 1 R 6 6 6 6 0 a 2 2 2 R R R R 5 i 6 o 0 0 0 0

R 5 5 5 5 i i i i 0 p 6 6 6 o o o o 0 0 0 0 0

i R R R 5 i 0 0 0 0 o o S 0 0 0 0 e R 4 0

0 5 5 5 i i i 0 p p p p p p p p p p p p p p p o o o F S S S S 0 a a a a a a a a a a a a a a a G G G 0 0 0

i i i 0 0 0 o o o p p p p p p p p p p s s s s s s s s s s s s s s s t F F F F S 0 0 0

a a a a a a a a a a

G G S F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r s s s s s s s s s s F N N N S S S

sup 0 sup 0 sup 0 2 M o 0 0 0 0 0 0 0 0 0 0 F F F N N sup 0 sup 0 5 8 D D D S F S F S F D J J J a 2 3 2 M M M D D T 1 S S S J J 3 9 2 D D D i S S 0 T T T e P P P P P I I I I I P P P P P 1 1 1 6 _ _ _ _ _ T T - - - 2 2 2 5 P P P P P P P P P P I I I I I I I I I I R U U U U U X X X - ______0 0 0 - - I I I I I I I I I I 5 i c X X 6 6 6 o U U U U U U U U U U ______A A A A A H H H 0

R R R 0 U U U U U R R R R R A A A A A R R R R R A A A A A H H r 0 - - - 5 5 5 i i i o o o S i A A A A A S S S S S 0 0 0 R R R R R R R R R R T T T T T 0 0 0

- - 0 0 0 s p p p p p p p F 0 0 0 0 0 R R R R R _ _ _ _ _ 5 5 5 a a a a a a a _ _ _ _ _ G S T T T T T T T T T T p p p p p p p p p p p p p p p p p p p p p s s s s s s s S S S t 4 4 4 4 4 H H H H H 5 5 a a a a a a a a a a a a a a a a a a a a a

- - - - - G G G - - - T T T T T _ _ _ _ _ 0 0 0 0 0 0 0 P s s s s s s s s s s s s s s s s s s s s s e F F F N 5 4 3 2 1 P P P 8 8 8 8 8 sup 0

H H H H H - - _ _ _ _ _ U U U U U 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 N N N I P P 5 5 5 5 5 sup 0 sup 0 sup 0 D I I I H H H H H a _ U U U U U B B B B B J N N N - - - - - D D D I I 5 4 3 2 1 U U U U U 5 S J J J B B B B B _ _ _ _ _ N N / - - - D V 1 1 1 1 1 S S S B B B B B _ _ _ _ _ R R R T - - S S S S S S S - - - - - 2 2 2 2 2 _ _ _ _ _ R R _ T T T - 5 4 3 2 1 T S S S S S S S S S S S S S S S S S S S S S O O O P P P P P P P o - - - - - X 3 3 3 3 3 4 - - - 5 4 3 2 1 O O P P P P P P P P P P P P P P P P P P P P P I I I I I I I - - - - - X X X U U U ______H _ c R 5 4 3 2 1 I I I I I I I I I I I I I I I I I I I I I U U T 4 4 4 4 4 4 4 ______H H H P N N N - 2 2 u ------3 3 3 3 3 3 3 2 2 2 2 2 2 2 1 1 1 1 1 1 1 0 N N 7 6 5 4 3 2 1 - - - D D D ------0 0 0 m 7 S 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 L D D - - - 7 7 7 - P P P P - - - - - e P P A A A P P P 2 I N A A n D D D I I I N N N D D - 3 t R - - - s R R R O / 2 O O O p U U U U i N A A A A + P - N N N A A A A + P 3 s D D D D I D _ A A A A + P A A A A + P 3 V D D D D I D D D e C C C C - _ 5 3 3 V D D D D I D D D D I P 3 C C C C - - - _ _ 5 S V 2 2 1 1 b V V P P P 3 A _ C C C C C C C C 5 5 V 4 4 3 3 - + - + 3 3 A A A _ S / D A V V 8 8 7 7 6 6 5 5 - + - + v _ _ S D D D M - + - + - + - + S S 1 M O P S S S R + P S S S R + P M M - O G S S S R + P G S S S R + P 3 3 i O P P P I P P P I o P P 0 O O D _ _

3 3 i i i 0 O V V P P P I P P P I o o o P P N N I I I I I I I I T _ _

5 5 / ______0 0 0 O O V V _ _ 3 3 I I I I I I I I v T D D 5 5 H S F V V ______S M M S M M _ _ C C 3 3 I T T 4 M H S F S F S F V V 1 S M M S M M C C C C 0 S S 4 4 3 I O I O M M M H H D S S C C

4 2 8 . S S I O I O C L L D D D 6 5 1 i o S S S S 0 O O 2

L L K K 8 7 1 1 1 i i 0 o o S S S 0 I I O O 2 2 2

. K K i 0 0 o 6 0 0 0 I I s

S F i i 0 R o o 6 6 6 2

M S F S F c i 0 0 R R R 5 i o o 6 3 3

M M S F 0

i 0 5 5 5 i i i 0 o o o o h 4 0 0 3

M S F S F 0 0 0

D D 1 0 0 0 0 o S 2 0 0 0 3 4 2 M M S F D

1 1 S F S S S 9 1 0 4 ( 2 2 M S F D D 1 6 F F F 3 0 0 S 4 2 M D 1 1 R 6 6 5 3 3 0 2 2 D 1 R R 5 i c 6 o h 0 0 2 0

1 R 5 5 i i 0 6 6 o o 0 0 2 o 0 0 e R R 5 i 0 0 6 o S 0 0 0 0

R 5 5 i i 0

p p p p p p p p p p p p p p GNDp A p p p p p p p p p p p p p 6 o o F S S e 0 a a a a a a a a a a a a a a a a a a a a a a a a a a a a k 0 0

i i R 5 i 0 0

GNDA GNDA GNDA o o s s s s s s s s s s s s s s s s s s s s s s s s s s s s o F F S

sup 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 i 0 t o F S S

sup 0 sup 0 0 sup 0 c 0

: i i 0 o o F F S 0

S F S F 0 0 J J J J F e S 6 3 2 M M S S S S F 1 7 S F S F D D / k T T T T 3 3 M M 8 P P P P P P P P P P P P P P P P P P P P P P P P P P P P 1 1 5 3 - - - - 2 2 D D I I I I I I I I I I I I I I I I I I I I I I I I I I I I X X X X ) t ______0 0 1 1 6 6 A A A A A A A A A A A A A A A A A A A A A A A A A A A A H H H H 2 2 e R R s D D D D D D D D D D D D D D D D D D D D D D D D D D D D 0 0 - - - - 5 5 i i 6 6 o o 0 0 0 0 C C C C C C C C C C C C C C C C C C C C C C C C C C C C 0 0

R R 0 0 0 0 7 7 7 7 ______5 5 i i o o S S 0 0 4 4 4 4 4 4 4 3 3 3 3 3 3 3 2 2 2 2 2 2 2 1 1 1 1 1 1 1 - - - -

t 0 0 F F P P P P 0 0 ------7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 S S I I I I s F F N N N N p p p p p p p p p p p p p p a a a a a a a a a a a a a a - - - - G G p p p p p p p p p p p p p p s s s s s s s s s s s s s s R R R R a a a a a a a a a a a a a a

0 0 0 0 0 0 0 0 0 0 0 0 0 0 s s s s s s s s s s s s s s N sup 0 N sup 0

O O O O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 D D J J U U U U S S J J N N N N S S T T S S S S S S S S S S S S S S D D D D T T - - S S S S S S S S S S S S S S P P P P P P P P P P P P P P X X ------P P P P P P P P P P P P P P I I I I I I I I I I I I I I X X P P P P ______H H I I I I I I I I I I I I I I A A A A 6 6 6 6 6 6 6 5 5 5 5 5 5 5 ______H H ------8 8 8 8 8 8 8 7 7 7 7 7 7 7 0 0 D D D D 7 6 5 4 3 2 1 7 6 5 4 3 2 1 ------0 0 7 7 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 7 - - P P - - P P I I N N I I 4 4 N N - - R R - - R R O O O O U U U U N N S S + P S S + P N N S S + P S S + P 3 3 C D I C D I D D _ _ 3 3 V V C D I C D I D D L A L A - - _ _ 5 5 S S + P V V P P 3 3 L A L A - - _ _ 5 5 _ _ V V 3 i i C D I o o P P 3 3 A A _ _ _ 3 3

_ _ V V 3 3 i i 0 0 V o o A A L A 3 3

D D 5 V V 3 3 0 0 V V 3 _ D D S F S F V V _ V i V V 3 3 o 3 3 7 5 3

M M S F S F 3 0 3 3 3 3 1 9 M M V D D V 1 S F D D 1 1 3 3 1 2 2 M 1 1 3 0 0 2 2 D 6 6 0 0 1 R R 6 6 2 i i R R 5 5 i i o o o o 0

0 0

i i 0 0 5 5 i i 0 0 o o 6 o o 0 0

0 0

0 0 R 0 0 S S 0 0 S F S F i 5 i o o F F S S 8 6

M M S F S F 0

0 0 F F 0 1 1 M M D D S 2 0 S F D D 1 1 F 1 2 2 M 1 1 4 0 0 2 2 D 6 6 0 0 1 R R 6 6 2 R R 5 5 i i p p p p p p p p p p o o 0 a a a a a a a a a a G G 0 0

5 5 i i 0 0 p p p p p p p p p p 6 s s s s s s s s s s o o 0 0 a a a a a a a a a a

G G 0 0

0 0 0 0 0 0 0 0 0 0 R 0 0 s s s s s s s s s s N N S S

0 0 sup 0 sup 0

0 0 0 0 0 0 0 0 0 0 5 i p p p p p o F F N N sup 0 S sup 0 S a a a a a D D G 0

0 J J s s s s s F F 0

D D 0 0 0 0 0 S S J J N sup 0 S I I S S F 2 T T D I I I I I I I I I I 5 5 J 2 2 2 2 2 2 2 2 2 2 C T T - - 2 I I I I I I I I I I S C C C C C C C C C C X X 2 2 2 2 2 2 2 2 2 2 - -

C C C C C C C C C C X X c ______T H H I I I I I 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 a ______H H - - - C C C C C X ------4 4 4 4 4 3 3 3 3 3 n 0 0 C 5 4 3 2 1 5 4 3 2 1 ------_ _ _ _ _ H

0 0 5 5 5 4 3 2 1 5 4 3 2 1 s 5 5 5 5 5 5 5 - - - u - - - - - P P 0 - - 5 4 3 2 1 p P P 5 I I p N N I I -

N N o P - - R R r - - I S t N R R

O O u - O O p U U R U U

N N S S + P S S + P O t o o N N S S + P S S + P 3 3 C D I C D I D D U

_ _ 3 3 V V C D I C D I 1 D D L A L A - - _ _ 5 5 N S S + P V V 0 P P 3 3 L A L A - - _ _ 5 5 _ _ V V 3 i i C D I D o o P P 0 3 3 A A _ _ _ 3 3

c _ _ V V 3 3 i i 0 0 V o o 8 A A L A - 3 3

D D 5 V V 3 3 0 0 V V P 3

_ D D S F S F V V _ V i V V s 3 3 o 3 3 A 1 1 3

M M S F S F 3 0 l 3 3 3 3 k 7 5 a 2 1 M M D V D D V 1 9 v S F D D 1 1 3 3 e 3 2 2 M 1 1 6 0 0

2 2 D e d 6 6 0 0 1 R R 6 6 e 2 i i R R 5 5 i i o o o o v 0

0 0

i i 0 0 5 5 i i 0 0 o o 6 o o i 0 0

0 0

c t 0 0 R 0 0 S S 0 0 S F S F e i 5 i o o F F S S 1 1

M M S F S F 0

s s 0 0 F F 8 6 0 2 2 M M D D S 2 0 S F D D 1 1 F 3 2 2 M 1 1 7 0 0 6 6 2 2 D 6 6 0 0 1 R R 6 6 2 R R 5 5 i i p p p p p p p p p p o o 0 a a a a a a a a a a G G 0 0

5 5 i i 0 0 p p p p p p p p p p 6 s s s s s s s s s s o o 0 0 a a a a a a a a a a

G G 0 0

0 0 0 0 0 0 0 0 0 0 R 0 0 s s s s s s s s s s N N S S

0 0 sup 0 sup 0

0 0 0 0 0 0 0 0 0 0 5 i p p p p p o F F N N sup 0 S sup 0 S a a a a a D D G 0

0 J J s s s s s F F 0

D D 0 0 0 0 0 S S J J N sup 0 S S S F T T D I I I I I I I I I I J 2 2 2 2 2 2 2 2 2 2 T T - - I I I I I I I I I I S C C C C C C C C C C X X 2 2 2 2 2 2 2 2 2 2 - - C C C C C C C C C C X X ______T H H I I I I I 2 2 2 2 2 7 7 7 7 7 6 6 6 6 6 ______H H - - - C C C C C X ------9 9 9 9 9 8 8 8 8 8 0 0 5 4 3 2 1 5 4 3 2 1 ------_ _ _ _ _ H 0 0 5 5 5 4 3 2 1 5 4 3 2 1 1 1 1 1 1 5 5 - - - 0 0 0 0 0 P P 0 ------P P 5 I I 5 4 3 2 1 N N I I - N N P - - R R - - I N R R O O - O O U U R U U N N O N N R D D U D D a - - N P P s - - D P P p A A b A A - D D P e D D A r r D y

P i 7 7

c o n n e c t o r

s o c k e t s S 2 v 1 5 h / . e 0 0 e 7 / t 2 : 0 1 6 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 1 U 9 Z H M S

X i i r c

B o 6 r / s 2 GND o G I 1 U e -

s U B 5 N - sup 0 S s S s V 5 s u B D P h H p p _ e V

A a 0 i I G s U e B E

U r 0 1 l N U S s D L 0 d D S I u 1 1 D D D S +

B / - - f B r m e _ _ a H GND H + i l h l U C y U L p s s s i i i s p 3

B o o o a u u u u a a B c

E 4 0 0 0 p p p p s s _

o 0 0 0 0 0 e 0 1 _ D F 0 C32 n V l _ u pas 1 pas 1 G U U 5 E n a p - f D G a V e R S S s N

a sup 0

3 1 10uf c _ N B B R D 2 R + 3 t p U Y . D e U U 2 _ _ 7 I _ C E T 8 S e K d H H p O p S S 2 L a

a E

6 B 1 L s s t U U t B B

/ O 0 o 1 r 1 _ B B 1 C _ _ W o 6

12MHZ p p H 0 G a a W 3 H H p _ _ - s s 0 a 5 a

pas 1 pas 1 W 2 1 U 1 0 n s N D D U U

1 C 1 f H i B D 0 P M e B B 3 I 0 T 6 ?

_ _ Y2 n p - E a f

p C25 c D D - s a

0 pas 1 pas 1

1 s 6 r P M

1 i i i i i i i i i i i i i i i i i o o o o o o o o o o o o o o o o o 0 i

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3

p p 10nf s D a a 3 L 1 1 1 2 2 1 1 1 1 1 2 2 2 2 s s 1 t 3 4

1 0 2 3 2 1 6 5 3 1 8 2 4 7 8 9 5 6 7 0 p e 0 a R s a 1 - 1 F U 3 R / 5 3 4 E D 0 $ 0 2 D D V V V V R X V B P O T X X V V 0 p R 1 6 a E M D D D D R B U W I O D S 5 P M E V s o N .

S 1 U S A V 1 U 3 3 1 1 X S S D C U U R c T 3 3 8 8 s T T S J 5 _ J T J _ _ J 2 2 p u J M U a O O s m S 1 B L L e _ D D D D D R E E D D D D T H n M M M M R in 0 D D P P P P P V U 2 1 4 3 2 1 4 3 2 1 t 1 P s B 5 / _ p I F i 4 5 6 7 8 9 1 1 2 2 2 E - 1 0 4 3 2 R s R i i i i i i i i i i i o o o o o o o o o o o e R

0 0 0 0 0 0 0 0 0 0 0 S T b I

in 0 T P / E U U U U U U U U T 1 v

in 0 4 P S S S S S S S S 3 1 1 B B B B B B B B 8 - 4 3 3 4 4 2 2 1 1 0 ______5 / D D D D D D D D v G C28

M P M P M P M P pas 1 pas 1

1 C29 N pas 1sup 0 pas 1 G . D 100nf 0 100nf N sup 0 D F . s T U U c D S S h I 2

B B pas 0 pas 0

_ ( 1 1 - + 3 S _ _ 3 3 V D D h 3 4.7uf C30 M P e i i i i i i i i i n n n n n n n n n e

0 0 0 0 0 0 0 0 0 2 1 1 1 2 2 1 2 t 4 5 6 5 7 8 7 9 0 :

U 7 5 G U U 3 O O R V V / V 8 C C S S E N S S 3 B B S C C C C D ) O F D D E I O I T O U T M P 2 T 3 2 R L C C C C C - S B B B B B T S G G G D D R D C T R U U U U U E O C N N N X S X T T S T S S S S S P R R D D R D D D D 5 S S T 2 4 3 2 1 0 I 8 V _ 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 U 1 1 8 6 2 4 3 2 3 0 S i i i i i i i i i i i i i i i i i n n n n n n n n n n n n n n n n n F F

B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 F F T T _ T T D D H D D I I G U 2 2 I I 2 2 _ _ B N sup 0 _ _ R T _ D R T E F E X X 4 4 E D D R p R a s

1 I T 1 R 0 E 2 K 7 BLUE-0603 F

330R T pas 0 pas 1pas 0 pas 1 p D a s

1 D7 R23 _ H U B _

GREEN-0603 L E

330R D pas 0 papsa 1s 0 pas 1 S D15 R24 5 5

G C31 N sup 0 pas 1 pas 1 D 100nf F F F T T T D D D I I I 2 2 2 _ _ _ R T T E X E D p p a w i i i n n n s r

0 0 0 0 0 5 2 3 4 8 G ~ D D V R C E I N 6 6 E C D U S 1 P 2 4 8 3 E C R O B A N - L 7 6 1 U i i o o o u

0 0 t

0 R R F S T S S D 4 4 B I 8 8 2 5 5 _

_ _ R H B A X G D N sup 0 U D i i o o

B 0 0 7 7

io 0 S W B B a Cio O0 M 1 COM n M K d - 1

io 0 A 2 C

a A 0 R s 2

G i i o o 1 R

1 0 0 S . 2 5 2 G 0 5 R 4 N sup 0 D 8 p a 5 s

1 S 2 v 1 5 h / . e 0 0 e 7 / t 2 : 0 1 7 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 1 9

/ C38 pas 1 pas 1 U

s 100nf e

C42 G pas 1 pas 1 r N

s sup 0 1 1 100nf D / m G i N sup 0 h pas 0 pas 0 D a - + G e

5 C39 N l spuaps 01 pas 1 V

a 47uf C40 pas 0 pas 0 D _ a - + 100nf F U G T p

C43 S D N

e spuaps 01 pas 1

47uf C44 B I D U U 3 t _ F

r 100nf S S _ H o T 3 B B U D V a 2 2 B I 3 U U _ _ i 4 _ e D D S S _ F - 3 M P B B E c V 3 3 R r 3 _ _ i R i i i i i i i i i D D s n n n n n n n n n

0 0 0 0 0 0 0 0 0 I M P t T 2 1 1 1 2 2 1 2 e 4 5 6 5 7 8 7 9 0 E 5 U a V 1 i i i i i i i i i n n n n n n n n n _ / 3 G U U 3 O O R V V

0 0 0 0 0 0 0 0 0 D U V 2 1 1 1 2 2 1 2 C C S S E N S S 4 5 6 5 7 8 7 9 0 3 S B B S C C C C o D O U F B D D E I O I T O c 1 U T M P _ 2 4 G U U 3 O O R V V 2 2 u T 3 H V C C S S E N S S 2 m 3 R U B B S C C C C D O F L D D E I B O I C C C C C - T O U e S T M P 2 B B B B B _ T S T G G G 3 D D R D n C T R U U U U U F E O 2 C N N N X S X T T S T R E S S S S S t P R R D D R D D D D s S S L T 2 4 3 2 1 0 R C C C C C I - 8 S / B B B B B R T p S G G G D D R D C T R U U U U U E O I 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 C i N N N T X S X T T S T 1 S S S S S 1 8 6 2 4 3 2 3 0 P - R R D D R D D D D E S S T 2 4 3 2 1 0 s i i i i i i i i i i i i i i i i i n n n n n n n n n n n n n n n n n I 8 R T

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 e X X b 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 D D 1 1 8 6 2 4 3 2 3 0 / 1 G 1 i i i i i i i i i i i i i i i i i n n n n n n n n n n n n n n n n n v

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 N sup 0 1 D - R T 0 G X X

/ BLUE-0603 D N v sup 0 D 2 D 1 2 330R pas 0 papsa 1s 0 pas 1 . 0

D16 R29 F . T s D c I _ h H

( BLUE-0603 GREEN-0603 U S B 3 330R 330R 3 _ h pas 0 pas 1pas 0 pas 1 pas 0 papsa 1s 0 pas 1 F L e T

D18 R31 D17 R30 E D e D I t _ S : H

8 U / B

8 GREEN-0603 _ ) 330R L

pas 0 pas 1pas 0 pas 1 E

D19 R32 D S 4 4 p a s

1 p a s

1 1 C 1 0 2 0 C 0 4 0 n 2 n f 1 f G G p

a C23 s N N

sup 0 pas 1 sup 0 pas 1 1 p a D D s

1 100nf T R p a X S s

1 D 2 3 3 p 2 a s 1

_ 1 0 C 0 3 2 n _ 0 f p R 1 a 0 s C X

0 1 2 n D 2 f p a s

1 5 5 p p o a w u i i i i i i i i i i i i i i i i n n n n n n n n n n n n n n n n s r t

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 2 1 2 2 1 1 1 6 7 4 9 0 7 6 5 4 2 5 4 1 0 8 3 7 3 G V C C C C ~ E D D D D R R R R R V V S - N + C 2 2 1 1 I I I I I I I I I N N N N N N N N N N H - + - + C D 4 3 2 1 5 4 3 2 1 D U N M 4 A X 2 R R R R R D D D D 1 O O O O O O O O O 3 U U U U U U U U U I T T T T T T T T T D 5 4 3 2 1 4 3 2 1 B R 1 2 2 5 8 2 1 3 2 9 2 6 8 o o o o o o o o o u u u u u u u u u t t t t t t t t t

0 0 0 0 0 0 0 0 0 R R X S 6 6

C46 D 2

pas 1 pas 1 3 3 2 G 100nf _

C47 3 N spuaps 01 pas 1 G _ D T N sup 0 100nf F X D T D 5 D V I U U 5 _ S S _ pas 0 pas 0 U 3 B B - + S V 4 4 B 3 _ _ _

D D 47uf C48 H M P U U B _ S i i i i i i i i i n n n n n n n n n F

0 0 0 0 0 0 0 0 0 2 1 1 1 2 2 1 2 E 4 5 6 5 7 8 7 9 0 B R U R 1

5 G U U 3 O O R V V I V T H C C S S E N S S 3 E B B S C C C C D O F D D E I O I T O U U T M P 2 T 3 2 B R L 7 7 C C C C C - S B B B B B

T S G G G D D R D C T R U U U U U E T O C N N N X S X T T S T S S S S S P R R D D R D D D D S S T 2 4 3 2 1 0 O I 8 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1

1 1 8 6 2 4 3 2 3 0 U i i i i i i i i i i i i i i i i i n n n n n n n n n n n n n n n n n R T

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X X A D D 3 G 3 R

N sup 0 D T S 2 v 1 5 h BLUE-0603 / . e 0 0 330R

e pas 0 papsa 1s 0 pas 1 7 / t 2 : D20 R33 0 1 8

9 SW5 TS-1101F 8 io 0 io 0 8

/ 1 2

8 1 2 2

GREEN-0603 F 0 T

: 330R D

3 pas 0 papsa 1s 0 pas 1 I 7 D21 R34 _ H U B _ L E D S D C E B A

Appendix B

PiSEB v2.0 Eagle Schematics

This appendix includes the Eagle Schematics of the second version of the PiSEB board.

109 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 0 2

/ U s e r s 1 1 / m J 1 i h 0 MICRO USB , a J

3 J1 e J6, HDMI T , l H C a E A a R M p

N J7, A/V E e E R J t T 4 A r MICRO SD (bottom) , o

D a I S i e P G - L c P A r I G Y O i s P 2 t I 6 O e 1 a

9 J9 / _ + D F 3

J DO NOT USE these pins for anything other o R V 1 than attaching an I2C ID EEPROM. Leave 1 E 3 c unconnected if ID EEPROM not required. P P , S S G S S E 2 2 u

$ $ 2 P P C D + P 4 4 m

These pins are reserved for ID EEPROM I S S S S X 3 D I I L A 1 2 I G G

Raspberry Pi 2 _ _ P P P P O

V _ U _ G _ e At boot time this I2C interface will be G G P P I I I I 3 4 3 S 3 _ _ _ _ S

interrogated to look for an EEPROM P n P P R R I I + V V S M M G D O O

B that identifies the attached board and I U U I I 3 t 3 O 3 C O O P I O 6 5

s allows automagic setup of the GPIOs V N N S 1 L I

(and optionally, Linux drivers). 2 1 / S _ _ 3 O

GND GND O GND 3 K p 1 2 I 3 i

*ID_SD and ID_SP C PIP NS: P P P P P P P P P P P P P - P P P P P $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ s $ $ $ $ $ 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1 e 9 7 5 3 1 9 7 5 3 1 9 7 5 3 1 9 7 5 3 1 b / G G G G G G I G G G G 3 G G G G G G G 3 G J D v J V V 8 N P P P P P N P P P P P P N P P P _ P 1 3 3 2 I I I I I I I I I I I I I I D D D S O O O O O O O O O O O O O O 2 I O - D , 2 1 1 6 5 1 9 1 2 2 1 4 3 2 0

* 1

6 9 3 0 2 7 7 2 E / X v x

p U G G G G G G G G G G 2 I a G G D S P P P P P P P P P P . n _ P P G G G G G 0 I I I I I I I I I I B O O O O O O O O O O s S I I N N N N N O O . i 5 5 C 2 2 1 1 2 2 2 1 1 1 o s D D D D D V V 7 8 1 0 6 2 5 4 3 8 5 4 * n c h P P P P P P P P P P P P P P P P P P P P

$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ ( 4 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1 8 6 4 2 S 0 8 6 4 2 0 8 6 4 2 0 8 6 4 2 0 3 3 h e G G G G I S S G G S G P P P D e P P P I I I P P P P P P P _ _ _ _ t I I I I I I I I I I T T 5 S : 0 0 _ O O O O O O O

V T T _ _ G C 1 2 2 1 1 2 2 1 L L C C GND P 1 0 6 2 5 4 8 / _ _ S S 8 _ _ _ _ _ I _ R T O 1 0 F F F F F F ) X X 4 R R R R R R D D E E E E E E E E E E E E

GND GND GND GND

G +3V3 C11 N

G +3V3 A D C2 t d N h 100nf d e D G D 4 4 r

100nf o o N P s n

D P w - s l y G : I e c

C13 S 0 r b N

V 1 5 w C 1 a 2 o - D V 2 0 a t L t 0 100nf 0 n e _ A G +3V3 0 t r 3 V

d y N B 0 r t S S S S S S V + h d

A 0 D h P P P P P P 3 T i r s o e t 1 I I I I I I

_ _ _ _ 0 0 l s + p d

s 1 G G G G _ _ 1 1 1 1 1 1 1 e e *

1 9 4 0 7 6 5 2 C C r 0 P P P P r 2 E m

S S x T o I I I I O O O O 6 e 1 0 n P 8 n 4 3 2 1

1 s N N V A A A S V a 7 e x S 2 1 0 C D R C C n e S L D _ t T l e M 2 y C d

1 1 1 1 U p p C _ 8 3 2 1 3 4 5 6 o B +3V3 1 P w A S 2 e a T 3 r T G 2 2 1 1 2 1 V * e R 0 A A A A ~ ~ C S N d G G G G G G G G E E E G G G G G G G G 1 0 1 0 R 1 C C I

D I n S P N S g N P P P P P P P P P P P P P P P P 7 U L D i E T A A A A A A A A B B B B B B B B T v 7 - _ A A B T 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 1 E e 4 3 5 5 n d 0 / V T H S I

t 3 h C O

e 8 7 6 5 4 3 2 1 2 2 2 2 2 2 2 2 2 1 1 1 G T e 8 7 6 5 4 3 2 1 0 9 8 3

P C N M 1 2 2 2 2 1 1 1 1 1 1 1 1 1 1 i D 0 R ~ ~ ~ ~ ~ ~ ~ ~ 3

1 6 9 8 7 5 4 2 3 2 0 6 4 c R G G 4 Y Y Y Y Y Y Y Y 9 r a 1 S 3 2 1 0 3 2 1 0 P P D n D I I

G G G G G G G G G G G G G O O b u A G N N N N N N N N ~ S V V 0 R e P P P P P P P P P P P P P R R 1 1 C B C 1 _ ...... N C C C C C C C C

A A A A A A A A 7 9 1 1 1 7 6 5 4 B B B B B 3 2 S A 3 s L C D 1 ...... 0 2 7 6 5 4 3 2 1 0 T w 4 3 2 1 0 T ______V x D 8 7 6 5 4 3 2 U 3 i L P 1 R t c S 0 2 P 2 O 2 h K 3 1 _ P e ~ 2 2 S d Y I +3V3 N _ 3 I ? _ G S T

3 1 R

/ 2 I R R R R R R R R W S S G S S K

Q F56 +3V3 P P P P P P P P D N h H T W I I I I I I I I a A Z ______t E C C C C C C C C '

s SMD1206R500SF N S S S S S S S S

t G h 7 6 5 4 3 2 1 0 F57 3 1 1 J e N 5 5

1 1 1 1 1 1 1 b D 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0

a SMD1206R500SF t t S S 1 e 6 6 6 r D C p y S - A L

2 D l . i _ 5 _ f A 4 e 3 3

P V _ V l i 3 k I 3 3 _ J V e 6 5 1 1 1 1 1 1 ? 1 3 V 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 1 6 p - 2 . 5 4 F D P R H E i T

G E & N 2 G D P P +

I 2 I _ 7 7 3

O R 5 + 4 3 2 1 V R18 4 I V 3 D SCL_3V3 3 V

10K 2 3 P G A A A R16 B U 2 1 0 N R i 8 1 C 0

D +3V3 C I 2 g 10K 0 1 4 n I

9 V f S S G G G G W D G C D G G G G G G G G S F C 3 P P N 6 M C i R A P

L P P P P P P P P 2 2 I I D S F D O O P t - I I I I I I I I 6 M 1 P

3 R19 O O O O O O O O 0

I 2 6 5 P D

SDA_3V3 a 0 h 2 2 2 2 2 1 1 1 1 E 6 5 6 7 8 2 a 6 5 4 1 0 9 8 6

R 10K 0 s ______5 6 I u

0 F F F F F F F R 4 3 2 1 l 1 0 E 5 O R R R R R R R S . 0 8 F 0 E E E E E E E T U I I K D D S l E E E E E E E E $ F

P G N D V _ _ p M 7 l s S D 2 v . A S S N u C G T P u D l D D C 2 5 h . l J

- R N 1 u / . H e 1 1 1 1 1 1 1 0 0 0 p D 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0 U e

7 T p r M e P / t O 1 G 1 R 2 : s 6 - 6 K T 3 i S 0 N p s 6 s P - E t 2 1 D o 1 7 . N 5 M r 9 8 8 4 s / S

J 2 f O 1 o 1 1 1 1 1 1 1 1 0 r R 1 9 8 7 6 5 4 3 2 1 6 5 4 3 2 0

R37 i - 2 3 D c 1 3 7 H 6

3.9K V p T - 3 2 2 . 5 2 4 R38

3.9K D C E B A 2 4 / 0 6 / 2 0 2 0

1 3 : D C E B A 0 2 P

L L L

2 f p R15 O O O _ = LOPY_RST_EN S y P P P 0 I Y Y Y c 0R p G . _ _ _ o y 9 R43 R T 3 m c V 5 X X B o 3 D Q D 100K 1/10W

m G 3 U 0 0 / S F N U 7 M B A

9 o S D D U s S L R 1 +5V 1 2 O e R44 A 3 0 1 1 T 8 6 P r o R W R s 1 Y

100K 1/10W 5 - 7 L L S F T 0 / _ - 0 7 M m O O F P S 8 0 t D F P P 2 1 i l L L L R 2 Y Y P Q L U h 0 O O O O 3 S 6 _ _ 1 o 6 a P R R R T R R T

2 +5V Y B 5 A A A e _ X X S 0 _ _ _ S 0 D S 5V l D a M M C S a 1 I G 1 G 1 F L 3 I O G S a 8 K N G S W O N p

D GND I d - N 7 D G J e - D F S J N t

LOPY_3V3 S T

D 3V3 r J L L L L L L P P P P P P P P P P P P P 2 1

R45 P e T 3 - O O O O O o L L L L L P P P P P P P 2 2 2 2 1 1 1 1 1 1 1 1 1 1 X - O O O O O 1 3 2 1 0 9 8 7 6 5 4 3 2 0 9 8 4 3 2 1 0 P P P P P X a H

100K 1/10W P P P P P Y Y Y Y Y H o - i r Y Y Y Y Y _ _ _ _ _ 0 2 1 e G - U U U U U _ _ _ _ _ 0 5 2 U U U U U - N A A A A A

p 5 Q - c - A A A A A P R R R R R D P - 2 7 P p R R R R R . r T T T T T I L

R46 5 N i T T T T T I 4 0 0 0 0 0 B N s - - - - - S - 1 1 1 1 1 5 4 3 2 1 R S ------t 100K 1/10W 5 4 3 2 1 R i y 1 e o O 3 O n 8 a U W U N /

- D 7 N P L L L L L L L L L L P L L L L L L L L L L 2 2 D - Q O O O O O O O O O O O O O O O O O O O O F s I U D - _ o 8 P P P P P P P P P P P P P P P P P P P P P - P P A c Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y C W A y D J u ______2 D R U P P P P P P P P C M M S S C R T P T R 3 A m 0 _ X X 2 2 2 1 1 1 1 1 C D 2 S S S X X I O 5 S C 2 1 0 9 8 7 6 5 D D D 2 L A 1 D D e S O 0 R T / 1 0 _ 1 0 C R I n 8 R R S L L L t L C O O K s L P P / 0 R K p R Y Y 1 T 2 i _ _ - M 3 s V I P e S 3 J P 2 1 I 4 O _ b I _ T / T T v T L 2 2 1 L _ 2 _ - T p 0 R - X 2 . X D / 5 v 4 D 2 t e . 0 s . t s e 3 3 c d h

( P S I h L L L +

G O O O 5 e V P P P e L L L L P Y Y Y O O O O t I _ _ _ : P P P P O

S S 3 2 Y Y Y Y V C D

_ _ _ _ / 3 o L A 8 S M M C / n C C S ) I O L S F + S 8 M

L L L L L L L L L 2 O L 5 S 3 b O L O O O O O O O O D / K V P C I S F 1 o P P P P P P P P 7 2 Y M L 6 0 o Y Y Y Y Y Y Y Y D K _ 6 o 1 R ______3 t 2 S F 5 , P P P P P P P P V 0 8 M 0

6 2 1 1 1 1 1 2 2 2 3 0 t D R S h 5 6 7 8 9 0 1 2 P 1 5 F 2 0 e 0 0 6 S y R F S F

5 y 5 M a 0 9 0 D r S G 1 e F 2 G 4 4 N 0

6 N n D R J D 5 S J o G 0 S T 0 t J L L L L L N S T 7

- O O O O O L L L L L L L 1 1 1 1 1 1 1 X F d - O O O O O O O D 1 6 5 4 3 2 0 9 8 7 6 5 4 3 2 1 P P P P P X H o P P P P P P P Y Y Y Y Y H - Y Y Y Y Y Y Y _ _ _ _ _ i 0 1 - n I I I I I ______6 0 2 2 2 2 2 5 S S S S S S S p C C C C C g 7 - - P P P P P P P P 2 ------

. 5 4 3 2 1 P I I I I I I I I 5 ------a N 7 6 5 4 3 2 1 4 I N n - R - J y R 9 O 1 1 1 1 1 1 1

O 1 6 5 4 3 2 0 9 8 7 6 5 4 3 2 1 U t o U N g N 1 D 6 D g p - - P 2 - l P . A i 5 n A 4 D g D , s o c o 5 5 n n e c t e d p 2 a n d m i s o d i r e c t l y t 6 6 o

G P I O p i n s u S P D y c

7 GND 7 o L L L L O O O O P P P P Y Y Y Y m _ _ _ _ C U 3 R V S S X 3 1 D D _ 1 S C L K 9 8 7 6 5 4 3 2 1 J 2 C D D V S V D C D S S C D 2 v D A O I S A M T T S L D N 5 2 h A A K I C / . 1 2 e 0 R 0 O e 7 S / t D 2 : - 9 0 P 1 2 9 8 8 / G

G G1 G4 2 G1 G4 N N 0 G2 G3 D

D G2 G3 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 0 J 2 1

/ U D C s - e 0 4 r 4 - s G A 1 1 / N m +24V_UNREG_IN D i h a e l 1 F a 1 F 8 1 a 2 A

U11 = 2 p

2 o e 2 n t 4 e r c 5 o

1 a V R20 a

ANODE l G l 3 i 5 N e 15K 1/10W

D 2 3 - NC CATHODE c T r G o

10uf C4 P i T C18 v s 8 N e P t D N r e 1 v 100nf 2 D e 6 8 o 1 a BZX84C30 e V l t - / d 5 a 2 1 D A s g

e g o

o p c o r A V 2 2 u o d D I +24V N t m e g J / c r G o D e t i N u o n L D n n U d t ? C U s $

p C 4 1 $ / l TAB D p a TAB 0 3 n M 6 i D U - e D s C $ I

I I G C f N N & 5 e o - O V D - + 2 r b

O C t 9 e / U - 3 v r S T D

+5V m 0 2 G T a 0 - E N l 0

P D i s 3 / - C s v D u O 2 O O e U S F U s . W 2 M T 0 T T D + N - . 1 P s 2 - 1 L 0 c 6 M R h G 5 2 G 0

5 N 0 ( G N S 9 2 1 S D F N 3 3 6 2 1 D J h D P J P e 2 1 e F 10uf C10 +5V T o t T : P r

P t 4 3 5 e 4 V s /

8 t & 3

5 ) o T o P p 1

o s h r

o p u r o l d b

e b s e

c l o s e

t o g e t h e r 4 4

G MK-12C02 G1.5 SW3 N D P P C I O _ M P A B i W

G R A C B P O N _ C M D T R o L

R40 T P 9

w 100K 1/10W

Q TP12 4 e R39 B S 5 5

S 100K 1/10W r 1 3 8

W +5V - C 7 Q - 2 F S 8 S 5 S 5 M o 0 T R26 3 J P 3 2 Q 1 n 10K 8 1 0 R 0 , L F t

r Q5 SSM3J328R,LF o l P I _ 5 Q V 9

R47 T P S 1

47K 8 1 5 6 6 5 0 P

+3V3 i

T f P G C12 P i 2 N D l 7 100nf 7 t S 3 L 3 L e 3 3 3 2 0 0 R R - - U 1 1 r 5 5 0 0

GNDA 0 0 M M C14 A A f T

100nf P o 3 + r 3 V

3 _ 3 S M O S 2 v V O 2 5 h T / . e 0 0 H e 7 3 / t 2 : 0 1 3 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 0 2

/ U s e r s 1 1 / m i h a e l a a p e t r o a i e - c r i s t e a / D o c 2 2 u m e n t s / p i - s e b / v 2 - 0 / v 2 . 0 . s c h

( S 3 3 h S e C e GNDA L t _ 1 S : GNDA +3V3_SMOOTH

3 1 C 4 A A A A A A A A 1 A A A A A A A A V 0 +3V3_SMOOTH L 1 1 / C7 C6 D D D D D D D D D D D D D D D D 3 _ 8 0

0 10uf C5 10uf C8 C C C C C C C C C C C C C C C C 3 1 0 ) V 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 1

100nf 0 100nf 1 + + - + - + - + - + - + - + - + - + 0 3

GNDA 3 3 0 V GNDA V 3 3 _ _ 1 1 1 1 1 1 1 1 1 1 S S 1 1 5 9 8 4 3 2 1 6 5 9 8 4 3 2 1 6 0 4 3 2 0 4 3 2 M M O O O O V A A S C C C C C C C C V V A A S C C C C C C C C V T T S D D C D S D D C D H H H H H H H H H H H H H H H H H H S S R R L D R R L D 4 4 3 3 2 2 1 1 4 4 3 3 2 2 1 1 - + - + - + - + - + - + - + - + 1 0 1 0 M M U U C C $ $ 2 1 P P 3 3 4 4 2 2 4 4 S S 4 4 D D - - E E A A / / S S L L 7 7 S S D D A A _ _ 3 3 V V 3 3 5 5 6 6 A D 7 7 C S 2 v 2 5 h / . e 0 0 e 7 / t 2 : 0 1 4 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 0

2 BLUE-0603

/ R35

U 5V_USB_HUB L s D11 1K E e D r _ s 1 1 G / m N RED-0603 D i h R22 LOPY_3V3 a

e D14100R l a a p e t r o a i e - c RED-0603 r +24V i R5 s t G e D4 1K N a D / C D O RED-0603 M o A B +5V c R6 2 2 u A C B m O D5 220R M e n

t RED-0603 s MK-12C02 G1.5 SW4 R7 /

p 5V35 i D6 330R - s e b / v 2 - 0 / v 2 . 0 RED-0603

. +3V3 s R9 c h D8100R

(

S RED-0603 3 3 h R10

e +3V3_SMOOTH e D9100R t :

/ RED-0603 8 R21 ) PI_5V D13220R

RED-0603 R4 PI_PWR_CTRL D22220R 4 4 5 5 6 6 L E 7 7 D s M H M H M H M H M H M H 6 5 4 3 2 1 O O O O O O U U U U U U N N N N N N S 2 v T T T T T T 2 5 h ------H H H H H H / . e 0 0 O O O O O O e 7 L L L L L L / t E E E E E E 2 : 3 3 3 3 3 3 0 ...... 0 0 0 0 0 0 1 5 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : R T R T + P P P + P 0 R R + P 3 3 X X I I I I X X _ _ _ _ 3 2 V V I S S D D D D _ 5 T T 5 R R V 3 3 2 2

2 1 5 R R + P V V 2 1 T T

3 3 3 S F V 3 / I L L S S 4 _ 2 2 M U V _ _ 8 4 4 5 S F _ _ D R T 3 8 8 5 M R V s 3 3 1 P P 0 X 2 5 5 X S F D _ _ e 0 5 M R R R R S S S R _ _ D 1 D R T 6 4 2 S F S S S R + r S D B A R P P P P P P P P X 0 X 4 s M P 1 3 5 P P P P 6 I I I 6 I I I I I D 1 1 2 I I 0 D D _ _ _ R V _ _ _ _ _ I / I I I 0 I 0 _ 2 m 1 _ _ _ 5 S M M _ C C C C C 6 3 S 2 5

S F 0 R S M M C F C 0 S S S S S 0 4 I O M V 3 5 i 6 S S C 9 S I O U R L 0 h D 7 6 5 4 1 R S S F O 0 L S F K 0 1 5 S S a 2 I O 5 2 M S F 0 K F 1 0 I 0 5 M S F S F D e 6 S 5 4 2 M M D 1 R F 7 8 l 2 D D 1 A S 5 a 0 2 J 0 1 1 6 0 1 0 a 2 2 R 4 3 2 1 6 2 S 0 0 R 5 p 6 6 F 0 R R 5 0 e R 4 0 5 5 S 0 G G G 4 0 0 t F S p 0 0 G G r F N N N - S S 2 o F F N N . 8 D D D S F 5 J J J a 2 M D D 4 T S S S J J 9 D i S S T T T e P P P P P I I I I I P P P P P 1 _ _ _ _ _ T T - - - 2 5 P P P P P P P P P P I I I I I I I I I I U U U U U X X X - ______0 - - I I I I I I I I I I c X X 6 U U U U U U U U U U ______A A A A A H H H R U U U U U R R R R R A A A A A R R R R R A A A A A H H r - - - 5 i A A A A A S S S S S 0 0 0 R R R R R R R R R R T T T T T 0 - - s 0 0 0 R R R R R _ _ _ _ _ 5 5 5 _ _ _ _ _ T T T T T T T T T T S t 4 4 4 4 4 H H H H H 5 5 - - - - - G G - - - T T T T T _ _ _ _ _ e F 5 4 3 2 1 P P P 8 8 8 8 8 H H H H H - - _ _ _ _ _ U U U U U N N P P 5 5 5 5 5 I I I H H H H H a U U U U U B B B B B N N N - - - - - D D I I 5 4 3 2 1 U U U U U J J B B B B B _ _ _ _ _ N N / - - - D 1 1 1 1 1 S S B B B B B _ _ _ _ _ R R R ------2 2 2 2 2 _ _ _ _ _ R R T T 5 4 3 2 1 T S S S S S S S S S S S S S S O O O o - - - - - 3 3 3 3 3 - - 5 4 3 2 1 O O P P P P P P P P P P P P P P - - - - - X X U U U c 5 4 3 2 1 I I I I I I I I I I I I I I U U T ______H H N N N 2 2 u 2 2 2 2 2 2 2 1 1 1 1 1 1 1 N N - - D D D ------0 0 m 7 6 5 4 3 2 1 7 6 5 4 3 2 1 L D D - - - 7 7 P P P - - - - e P P A A A P P A A n D D D I I N N D D t - - s R R / O O p T T U U i T T - N N s L L D D 3 3 e _ _ - - S b P P O O A A / U U v D D T T 2 P _ _ S S S R S S S R + P - R T 3 P P P P P P I P P 0 _ X V X I I I I I I I I 5 / ______D 3 D v V S M M S M M C C I G 2 C C S S I O I O S S N

. L L 3 2 S S 0 O O D K K J S I I . S s S F T 2 M P P P P P c 6 - D I I I I I X h _ _ _ _ _ 1 o U U U U U H 2

0 A A A A A ( - 6 S 0 R R R R R R 3 3 5 T T T T T 5 c h 0 - _ _ _ _ _ P 0 H H H H H e S I U U U U U F N e k B B B B B - t _ _ _ _ _ R : 1 1 1 1 1

S F O - - - - - e 6 2 M 5 4 3 2 1 U 7 D / 8 N 1 2 D ) t 0 6 - R P s 5 A 0 0 D S F A A A A + P G G A A A A 3 D D D D I N N _ A A A A A A A A + P V D D D D C C C C D D 5 3 D D D D D D D D I J J 3 C C C C _ V 2 2 1 1 V S S _ C C C C C C C C 5 4 4 3 3 - + - + 3 T T S A S S S S S S S S S S S S S S V 8 8 7 7 6 6 5 5 - + - + _ - - M P P P P P P P P P P P P P P - + - + - + - + X X S I I I I I I I I I I I I I I O ______H H M 6 6 6 6 6 6 6 5 5 5 5 5 5 5 - - O ------O D 0 0 7 6 5 4 3 2 1 7 6 5 4 3 2 1 T 7 7 O H S F - - P P T 4 M S F 0 4 M H I I D N N 2 C 4 4 D 1 2 - - S F 1 R R 0 4 2 M 6 1 0 O O D R 6 1 R 5 U U 2 S F 0

5 0 0 4 M N N 0 6 S 3 0 D S R D D F S 1 5 F - - 2 0 P P 0 0 6 S A A R F D D o 5

0 GNDA GNDA GNDA 0 GNDA S F c J J J J S S S S k T T T T P P P P P P P P P P P P P P P P P P P P P P P P P P P P - - - - I I I I I I I I I I I I I I I I I I I I I I I I I I I I X X X X ______A A A A A A A A A A A A A A A A A A A A A A A A A A A A H H H H e D D D D D D D D D D D D D D D D D D D D D D D D D D D D - - - - 0 0 0 0 C C C C C C C C C C C C C C C C C C C C C C C C C C C C S S S S + P 7 7 7 7 S S S S + P ______3 C D C D I _ 4 4 4 4 4 4 4 3 3 3 3 3 3 3 2 2 2 2 2 2 2 1 1 1 1 1 1 1 - - - - t 3 V C D C D I P P P P L A L A _ 5 ------V 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 3 L A L A _ _ 5 I I I I _ _ V s N N N N 3 _ _ 3 3 _ _ V 3 3 3 3 - - - - V V 3 3 V V R R R R S F V V V V 3 3 3 3 5 M S F O O O O 3 3 3 3 9 M D U U U U D 1 2 N N N N 1 0 2 5 5 D D D D 6 0 R 6 - - - - R 5 P P P P S F S F 0 5 A A A A 0 1 6 M M 0 S 0 0 D D D D D D F S 1 1 F 2 2 0 0 6 6 R R 5 5 0 0 0 0 S S G G F F G G N N N N D D J J D D S S J J I S S T T I I I I I I I I I I 2 2 2 2 2 2 2 2 2 2 T T - - 2 I I I I I I I I I I C C C C C C C C C C X X 2 2 2 2 2 2 2 2 2 2 - - I C C C C C C C C C C X X 2 ______H H 2 2 2 2 2 1 1 1 1 1 ______C H H ------4 4 4 4 4 3 3 3 3 3 0 0 C 5 4 3 2 1 5 4 3 2 1

------c 0 0 5 5 5 4 3 2 1 5 4 3 2 1 a 5 5 - - P P n - - P P

I I s N N I I

u N N - - p R R - - S p R R O O o O O U U r t U U

N N S S S S + P u o N N S S S S + P 3 C D C D I D D p _ 3 V C D C D I D D

L A L A 6 6 - - _ 5 t V P P 3 o L A L A - - _ _ 5 _ _ V P P 3 A A

_ _ 3 3 c _ _ V 3 3 1 A A 3 3 D D V V 3 3 V V 0 D D S F V V V V 3 3 0 3 3 1 M S F 3 3 3 3 k 5 8 1 M D 9

D 1 s 2 1 l 0 a 2 e 6 0 v R 6 e S F R 5 1

M S F 0 5 d 6 0 2 M 0 D t e S 0 0 D 1 F S v 2 1 s F i 0 2 c 6 0 e R 6 s R 5 0 5 0 0 S 0 F S G G F G G N N N N D D J J D D R S S J J S S a T T I I I I I I I I I I 2 2 2 2 2 2 2 2 2 2 s T T - - I I I I I I I I I I C C C C C C C C C C X X 2 2 2 2 2 2 2 2 2 2 p - - C C C C C C C C C C X X b ______H H 7 7 7 7 7 6 6 6 6 6 ______e H H ------9 9 9 9 9 8 8 8 8 8 r 0 0 5 4 3 2 1 5 4 3 2 1 - - r ------0 0 5 5 5 4 3 2 1 5 4 3 2 1 y 5 5 - -

P P P - - P P i I I 7 7

N N c I I N N o - - R R - - n R R O O n O O e U U c U U N N t o N N D D r D D

- - s P P - - o P P A A c A A D D k D D e t s S 2 v 2 5 h / . e 0 0 e 7 / t 2 : 0 1 6 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 0 U 2 Z H M S

X i i r c

B o 6 r / s 2 GND o G I 1 U e -

s U B 5 N - S s S s V 5 B D P h H _ e V A i I G U e B E U r 1 l N U S s D L 0 d D S I u 1 1 D D D S +

B / - f B r m e _ _ a H GND H i l h l U C y U L 3

B a B c E 4 _ o e 1 _ D F 0 C32 n V l _ u G U U 5 E n a f D G V e R S S N a

3 10uf c _ N B B R D 2 R 3 t p U Y . D e U U 2 _ _ 7 I _ C E T 8 S e K d H H O S S 2 L

6 B 1 L t U U t B B / O o r 1 _ B B 1 C _ _ W o 6

12MHZ H 0 G W 3 H H _ _ - 0 a 5 W U n N D D U U 1 C f H i B D 0 P M e B B 3 I 0 T 6 ?

_ _ Y2 n - E

f C25 c D D - 0 6 r P M 0 i

3 10nf s D 3 L 1 1 1 2 2 1 1 1 1 1 2 2 2 2 1 t 3 4 2 3 2 1 6 5 3 1 8 2 4 7 8 9 5 6 7 0 e 0 R a - 1 F U 3 R / 5 3 4 E D 0 $ 0 2 D D V V V V R X V B P O T X X V V 0 R 1 6 E M D D D D R B U W I O D S 5 P M E V o N . S U S A V 1 U 3 3 1 1 X S S D C U U R c T 3 3 8 8 s T T S J 5 _ J T J _ _ J 2 2 u J M U O O m S B L L e _ D D D D D R E E D D D D T H n M M M M R D D P P P P P V U 2 1 4 3 2 1 4 3 2 1 t 1 P s B 5 / _ p I F i 4 5 6 7 8 9 1 1 2 2 2 E - 1 0 4 3 2 R s R e R S T b I T P / E U U U U U U U U T 1 v 4 P S S S S S S S S 3 2 1 B B B B B B B B 8 - 4 3 3 4 4 2 2 1 1 0 ______5 / D D D D D D D D v G C28 M P M P M P M P

2 C29 N G . D 100nf 0 100nf N D F . s T U U c D S S h I 2 B B

_ ( 1 1 3 S _ _ 3 3 V D D h 3 4.7uf C30 M P e e 2 1 1 1 2 2 1 2 t 4 5 6 5 7 8 7 9 0 :

U 7 5 G U U 3 O O R V V / V 8 C C S S E N S S 3 B B S C C C C D ) O F D D E I O I T O U T M P 2 T 3 2 R L C C C C C - S B B B B B T S G G G D D R D C T R U U U U U E O C N N N X S X T T S T S S S S S P R R D D R D D D D 5 S S T 2 4 3 2 1 0 I 8 V _ 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 U 1 1 8 6 2 4 3 2 3 0 S F F B F F T T _ T T D D H D D I I G U 2 2 I I 2 2 _ _ B N _ _ R T _ D R T E F E X X 4 4 E D D R R I T 1 R 0 E 2 K 7 BLUE-0603 F

330R T D

D7 R23 I _ H U B _

GREEN-0603 L E

330R D S D15 R24 5 5

G C31 N

D 100nf F F F T T T D D D I I I 2 2 2 _ _ _ R T T E X E D 5 2 3 4 8 G ~ D D V R C E I N 6 6 E C D U S 1 P 2 4 8 3 E C R O B A N - L 7 6 1 U R R F S T S S D 4 4 B I 8 8 2 5 5 _

_ _ R H B A X G D N U D B 7 7

S W B B a COM 1 COM n M K d - 1

A 2 C A 0 R 2

G 1 R 1 S . 2 5 2 G 0 5 R 4 N D 8 5 S 2 v 2 5 h / . e 0 0 e 7 / t 2 : 0 1 7 9 8 8 /

8 2 0 : 3 7 D C E B A 2 4 / 0 6 / 2 0 D C E B A 2 0

1 3 : 0 2

/ C38 U

s 100nf e

C42 G r N s 1 1 100nf D / m G i N h D a G e

5 C39 N l V

a 4.7uf C40 D _ a 100nf F U G T p

C43 S D N e

4.7uf C44 B I D U U 3 t _ F

r 100nf S S _ H o T 3 B B U D V a 2 2 B I 3 U U _ _ i 4 _ e D D S S _ F - 3 M P B B E c V 3 3 R r 3 _ _ i R D D s I M P t T 2 1 1 1 2 2 1 2 e 4 5 6 5 7 8 7 9 0 E 5 U a V 1 _ / 3 G U U 3 O O R V V D U V 2 1 1 1 2 2 1 2 C C S S E N S S 4 5 6 5 7 8 7 9 0 3 S B B S C C C C o D O U F B D D E I O I T O c 1 U T M P _ 2 4 G U U 3 O O R V V 2 2 u T 3 H V C C S S E N S S 2 m 3 R U B B S C C C C D O F L D D E I B O I C C C C C - T O U e S T M P 2 B B B B B _ T S T G G G 3 D D R D n C T R U U U U U F E O 2 C N N N X S X T T S T R E S S S S S t P R R D D R D D D D s S S L T 2 4 3 2 1 0 R C C C C C I - 8 S / B B B B B R T p S G G G D D R D C T R U U U U U E O I 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 C i N N N T X S X T T S T 1 S S S S S 1 8 6 2 4 3 2 3 0 P - R R D D R D D D D E S S T 2 4 3 2 1 0 s I 8 R T e X X b 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1 D D 1 1 8 6 2 4 3 2 3 0 / 1 G 1 v N 2 D - R T 0 G X X

/ BLUE-0603 D N v D 2 D 2 2 330R . 0

D16 R29 F . T s D c I _ h H

( BLUE-0603 GREEN-0603 U S B 3 330R 330R 3 _ h F L e T

D18 R31 D17 R30 E D e D I t _ S : H

8 U / B

8 GREEN-0603 _ ) 330R L E

D19 R32 D S 4 4 1 C 1 0 2 0 C 0 4 0 n 2 n T T T f 1 f G G X X T C23 L D D N N 3 3 3 D D _

_ 100nf O T R C X U S O D T 2 N 3 _ 3 V 2 T _ 1 _ C R11 X

R1 0 C 0 3 D 2 O n _ 0 f N

0R R DNP 1 0 C V X 0 2 n D 2 f R13 R3 5 5 DNP 0R R R T T 1 1 1 1 1 1 2 2 2 2 1 2 2 1 1 X X 1 6 7 4 9 0 7 6 5 4 2 5 4 1 0 8 3 7 3 L D D 3 3 3 _ _ O C G V C C C C ~ E D D D D R R R R R V V U O S - N + C 2 2 1 1 I I I I I I I I I N N N N N N N N N N T H - + - + C N D 4 3 2 1 5 4 3 2 1 _ D V R U N M X 4 D A X 2 R R R R R D D D D 1 O O O O O O O O O 3 U U U U U U U U U I T T T T T T T T T D 5 4 3 2 1 4 3 2 1 B R 1 2 2 5 8 2 1 3 2 9 2 6 8 R R X S 6 6

C46 D 2 3 3 2 _ G 100nf _ C

C47 3 N O G _ D N T N

100nf F X V D T D 5 D V I U U 5 _ S S _ U 3 B B S V 4 4 B 3 _ _ _

D D 4.7uf C48 H M P U U B _ S F 2 1 1 1 2 2 1 2 E 4 5 6 5 7 8 7 9 0 B R U R 1

5 G U U 3 O O R V V I V T H C C S S E N S S 3 E B B S C C C C D O F D D E I O I T O U U T M P 2 T 3 2 B R L 7 7 C C C C C - S B B B B B

T S G G G D D R D C T R U U U U U E T O C N N N X S X T T S T S S S S S P R R D D R D D D D S S T 2 4 3 2 1 0 O I 8 2 1 7 2 1 1 1 2 2 6 1 9 2 1 3 5 1

1 1 8 6 2 4 3 2 3 0 U R T X X A D D 3 G 3 R N D T

BLUE-0603 330R S 2 v 2 5 h D20 R33 / . e 0 0 e 7 FTDI_HUB_LEDS / t 2 : GREEN-0603 0 C 1 330R 8 O 9 8 8 / M A B

8 D21 R34 2 0 A C B : 3 O 7 M

G MK-12C02 G1.5 SW2 N D D C E B A

References

[1] (2019). meta-virtualization. http://git.yoctoproject.org/cgit/cgit.cgi/meta- virtualization/. Accessed on 16 May 2019.

[2] Bug Labs, Inc (2017). freeboard. https://freeboard.io. Accessed on 28 April 2019.

[3] Abankwa, N. O., Bowker, J., Johnston, S. J., Scott, M., and Cox, S. J. (2018). Esti- mating the Longitudinal Center of Flotation of a Vessel in Waves Using Acceleration Measurements. IEEE Sensors Journal, 18(20):8426–8435.

[4] Aberer, K., Hauswirth, M., and Salehi, A. (2007). Infrastructure for data processing in large-scale interconnected sensor networks. Technical report, IEEE Computer Society.

[5] Aberer, K., Sathe, S., Chakraborty, D., Martinoli, A., Barrenetxea, G., Faltings, B., and Thiele, L. (2010). OpenSense: open community driven sensing of environment. In Proceedings of the ACM SIGSPATIAL International Workshop on GeoStreaming, pages 39–42. ACM.

[6] advancedtelematic (2019). meta-updater. https://github.com/ advancedtelematic/meta-updater. Accessed on 16 May 2019.

[7] Air-Go (2019). Air-go. http: // air-go .es . Accessed on 27 April 2019.

[8] AirPi (2019). Airpi. http: // airpi .es/ . Accessed on 31 March 2019.

[9] Anderson, J. C., Lehnardt, J., and Slater, N. (2010). CouchDB: the deﬁnitive guide. O’Reilly Media, Inc.

[10] Apetroaie-Cristea, M. (2019a). meta-remote-management. http://doi.org/ 10.5281/zenodo.2543575. Accessed on 16 May 2019.

[11] Apetroaie-Cristea, M. (2019b). meta-remote-management-raspberrypi. http:// doi.org/10.5281/zenodo.2542820. Accessed on 16 May 2019.

[12] Apetroaie-Cristea, M., Basford, P., Tiniuc, A., Johnston, S., and Cox, S. (2019). PiSEB PCB Schematics. https://doi.org/10.5281/zenodo.2545262. Accessed on 16 May 2019.

119 120 REFERENCES

[13] Apetroaie-Cristea, M., Scott, M., Johnston, S. J., and Cox, S. J. (2016). Indoor localisation system based on low-cost commodity hardware. In Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing: Adjunct, pages 13–16. ACM.

[14] Arnold, M., Hoydis, J., and ten Brink, S. (2019). Novel Massive MIMO Channel Sounding Data applied to Deep Learning-based Indoor Positioning. In SCC 2019; 12th International ITG Conference on Systems, Communications and Coding, pages 1–6. VDE.

[15] Ashton, K. et al. (2009). That ‘Internet of Things’ thing. RFID Journal, 22(7):97– 114.

[16] Atzori, L., Iera, A., and Morabito, G. (2010). The Internet of Things: A survey. In Computer networks, volume 54, pages 2787–2805. Elsevier.

[17] Augustin, A., Yi, J., Clausen, T., and Townsley, W. (2016). A study of LoRa: Long range & low power networks for the Internet of Things. Sensors, 16(9):1466.

[18] Bahena, V. R. (2014). Embedded distributed systems: A case of study with Clear Linux project for Intel R Architecture. Intel.

[19] Bai, H. and Shi, G. (2007). Gas sensors based on conducting polymers. Sensors, 7(3):267–307.

[20] Bakıcı, T., Almirall, E., and Wareham, J. (2013). A smart city initiative: the case of Barcelona. Journal of the Knowledge Economy, 4(2):135–148.

[21] balena.io (2017). balena.io. https://balena.io/. Accessed on 26 April 2019.

[22] Beckman, P., Sankaran, R., Catlett, C., Ferrier, N., Jacob, R., and Papka, M. (2016). Waggle: An open sensor platform for edge computing. In 2016 IEEE SENSORS, pages 1–3. IEEE.

[23] Bell, S., Cornford, D., and Bastin, L. (2015). How good are citizen weather stations? Addressing a biased opinion. Weather, 70(3):75–84.

[24] Bergen, M. H., Schaal, F. S., Klukas, R., Cheng, J., and Holzman, J. F. (2018). To- ward the implementation of a universal angle-based optical indoor positioning system. Frontiers of Optoelectronics, 11(2):116–127.

[25] Bernstein, D. (2014). Containers and cloud: From LXC to Docker to Kubernetes. IEEE Cloud Computing, 1(3):81–84.

[26] Bielsa, A. (2012). Smart City project in Serbia for environmental monitoring by Public Transportation. http://www.libelium.com/ smart_city_environmental_parameters_public_transportation_waspmote/. Accessed on 30 March 2019. REFERENCES 121

[27] Blair, S., Matheson, N., Munro, R., and Booth, C. (2019). A new platform for validating real-time, large-scale WAMPAC systems. In PAC World Conference 2019.

[28] Brewer, E. A. (2015). Kubernetes and the path to cloud native. In Proceedings of the Sixth ACM Symposium on Cloud Computing, pages 167–167. ACM.

[29] Brookes, D., Stedman, J., Kent, A., King, R., Venﬁeld, H., Cooke, S., Lingard, J., Vincent, K., Bush, T., and Abbott, J. (2013). Technical report on UK supplementary assessment under the Air Quality Directive (2008/50/EC), the Air Quality Frame- work Directive (96/62/EC) and Fourth Daughter Directive (2004/107/EC) for 2011. Report for the Department for Environment, Food and Rural Aﬀairs, Welsh Govern- ment, the Scottish Government and the Department of the Environment for Northern Ireland. Available online at: http://ukair. defra. gov. uk/assets/documents/reports/- cat09/1312231525_AQD_DD4_2012mapsrepv0. p df.

[30] Brunekreef, B. and Holgate, S. T. (2002). Air pollution and health. In The Lancet, volume 360, pages 1233–1242. Elsevier.

[31] Bulot, F. M., Johnston, S. J., Basford, P. J., Easton, N. H., Apetroaie-Cristea, M., Foster, G. L., Morris, A. K., Cox, S. J., and Loxham, M. (2019). Long-term ﬁeld comparison of multiple low-cost particulate matter sensors in an outdoor urban environment. Scientiﬁc reports, 9(1):7497.

[32] Caragliu, A., Del Bo, C., and Nijkamp, P. (2011). Smart cities in Europe. Journal of urban technology, 18(2):65–82.

[33] Carmichael, L. and Lambert, C. (2011). Governance, knowledge and sustainability: the implementation of EU directives on air quality in Southampton. Local Environ- ment, 16(2):181–191.

[34] Carr, J. and Doleac, J. L. (2016). The geography, incidence, and underreporting of gun violence: new evidence using ShotSpotter data. Incidence, and Underreporting of Gun Violence: New Evidence Using Shotspotter Data (April 26, 2016).

[35] Carruthers, K. (2016). Internet of Things and Beyond: Cyber-Physical Systems. http://iot.ieee.org/newsletter/may-2016/internet-of-things-and- beyond-cyber-physical-systems.html. Accessed on 25 April 2019.

[36] Catlett, C. E., Beckman, P. H., Sankaran, R., and Galvin, K. K. (2017). Array of things: a scientiﬁc research instrument in the public way: platform design and early lessons learned. In Proceedings of the 2nd International Workshop on Science of Smart City Operations and Platforms Engineering, pages 26–33. ACM.

[37] Chen, M., Mao, S., and Liu, Y. (2014). Big data: A survey. In Mobile Networks and Applications, volume 19, pages 171–209. Springer.

[38] Chodorow, K. (2013). MongoDB: the deﬁnitive guide. O’Reilly Media, Inc. 122 REFERENCES

[39] Codd, E. F. (1970). A relational model of data for large shared data banks. Com- munications of the ACM, 13(6):377–387.

[40] Cohen, J. E. and Tilman, D. (1996). Biosphere 2 and biodiversity: The lessons so far. Science, 274(5290):1150.

[41] Coleman, E., Goldstein, B., and Dyson, L. (2013). Lessons from the london datastore. Beyond transparency: open data and the future of civic innovation, pages 39–50.

[42] Cox, S. J., Cox, J. T., Boardman, R. P., Johnston, S. J., Scott, M., and O’Brien, N. S. (2014). Iridis-pi: a low-cost, compact demonstration cluster. Cluster Computing, 17(2):349–358.

[43] Davis, N. (2015). Wanted! An army of citizen scientists to tackle air pollution. The Guardian. Online at https://www.theguardian.com/environment/2015/aug/ 30/citizen-scientists-tackle-air-pollution, Accessed on 22 December 2019.

[44] Devarakonda, S., Sevusu, P., Liu, H., Liu, R., Iftode, L., and Nath, B. (2013). Real-time air quality monitoring through mobile sensing in metropolitan areas. In Proceedings of the 2nd ACM SIGKDD International Workshop on Urban Computing, page 15. ACM.

[45] Dohr, A., Modre-Opsrian, R., Drobics, M., Hayn, D., and Schreier, G. (2010). The Internet of Things for ambient assisted living. In Information technology: new generations (ITNG), 2010 Seventh International Conference, pages 804–809. IEEE.

[46] Dolstra, E. and Löh, A. (2008). NixOS: A purely functional Linux distribution. In ACM Sigplan Notices, volume 43, pages 367–378. ACM.

[47] Edwards, C. (2013). Not-so-humble Raspberry Pi gets big ideas. Engineering & Technology, 8(3):30–33.

[48] Ely, D., Savage, S., and Wetherall, D. (2001). Alpine: A user-level infrastructure for network protocol development. In USITS, volume 1, pages 15–15.

[49] Eroglu, Y., Erden, F., and Guvenc, I. (2019). Adaptive Kalman Tracking for Indoor Visible Light Positioning. arXiv preprint arXiv:1909.12985.

[50] European Comission (2016). Amsterdam is the European Capital of Innovation 2016. http://ec.europa.eu/research/index.cfm?pg=newsalert&year=2016&na=na- 080416. Accessed on 26 April 2019.

[51] Fainelli, F. (2008). The OpenWrt development framework. In Proceedings of the Free and Open Source Software Developers European Meeting.

[52] Feng, Z. (2011). Research on water-saving irrigation automatic control system based on Internet of Things. In Electric Information and Control Engineering (ICEICE), 2011 International Conference on, pages 2541–2544. IEEE. REFERENCES 123

[53] Forsström, S. and Jennehag, U. (2017). A performance and cost evaluation of combining OPC-UA and Microsoft Azure IoT Hub into an industrial Internet-of-Things system. In 2017 Global Internet of Things Summit (GIoTS), pages 1–6. IEEE.

[54] Fukuda-Parr, S. (2016). From the Millennium Development Goals to the Sustainable Development Goals: shifts in purpose, concept, and politics of global goal setting for development. Gender & Development, 24(1):43–52.

[55] Gartner (2017). Gartner Says 8.4 Billion Connected “Things” Will Be in Use in 2017, Up 31 Percent From 2016. Accessed on 26 April 2019.

[56] Geissler, J.-B., Tricarico, L., and Vecchio, G. (2017). The construction of a trading zone as political strategy: a review of London Infrastructure Plan 2050. In GLA Intelligence.

[57] GeSI (2019). DigitalAccessIndex. Online: https: // digitalaccessindex- sdg .gesi .org/ .

[58] Gomez, C., Oller, J., and Paradells, J. (2012). Overview and evaluation of bluetooth low energy: An emerging low-power wireless technology. Sensors, 12(9):11734–11753.

[59] Greenspan, J. and Bulger, B. (2001). MySQL/PHP database applications. John Wiley & Sons, Inc.

[60] Guth, J., Breitenbücher, U., Falkenthal, M., Leymann, F., and Reinfurt, L. (2016). Comparison of IoT platform architectures: A ﬁeld study based on a reference architecture. In 2016 Cloudiﬁcation of the Internet of Things (CIoT), pages 1–6. IEEE.

[61] Haines, N. (2015). The Future of Ubuntu. In Beginning Ubuntu for Windows and Mac Users, pages 205–209. Springer.

[62] Hart, J. K. and Martinez, K. (2006). Environmental Sensor Networks: A revolution in the earth system science? Earth-Science Reviews, 78(3):177–191.

[63] He, J., Liu, H., and Salvo, A. (2019). Severe air pollution and labor productivity: Evidence from industrial towns in China. American Economic Journal: Applied Economics, 11(1):173–201.

[64] Hendrawan, I. N. R. and Arsa, I. G. N. W. (2017). Zolertia Z1 energy usage simu- lation with Cooja simulator. In 2017 1st International Conference on Informatics and Computational Sciences (ICICoS), pages 147–152. IEEE.

[65] Hightower, K., Burns, B., and Beda, J. (2017). Kubernetes: up and running: dive into the future of infrastructure. " O’Reilly Media, Inc.".

[66] Ho, E. (2017). Smart subjects for a Smart Nation? Governing (smart) mentalities in Singapore. In Urban Studies, volume 54, pages 3101–3118. SAGE Publications Sage UK: London, England. 124 REFERENCES

[67] Jackson, K. R., Ramakrishnan, L., Muriki, K., Canon, S., Cholia, S., Shalf, J., Wasserman, H. J., and Wright, N. J. (2010). Performance analysis of high performance computing applications on the amazon web services cloud. In 2nd IEEE international conference on cloud computing technology and science, pages 159–168. IEEE.

[68] Johnston, S., Apetroaie-Cristea, M., Scott, M., and Cox, S. (2016a). Applicability of commodity, low cost, single board computers for Internet of Things devices. In World Forum on Internet of Things (WF-IoT) 2016, pages 1–6.

[69] Johnston, S. J., Apetroaie-Cristea, M., Scott, M., and Cox, S. J. (2016b). Applied Internet of Things. In Buyya, R. and Dastjerdi, A. V., editors, Internet of Things Principles and Paradigms, chapter 15, pages 277–297. Elsevier, 50 Hampshire Street, 5th Floor, Cambridge, MA 02139, USA.

[70] Junyan, L., Shiguo, X., and Yijie, L. (2009). Application research of embedded database SQLite. In 2009 International Forum on Information Technology and Appli- cations, volume 2, pages 539–543. IEEE.

[71] Kakakhel, S. R. U., Mukkala, L., Westerlund, T., and Plosila, J. (2018). Virtual- ization at the network edge: A technology perspective. In 2018 Third International Conference on Fog and Mobile Edge Computing (FMEC), pages 87–92. IEEE.

[72] Kelly, K., Whitaker, J., Petty, A., Widmer, C., Dybwad, A., Sleeth, D., Martin, R., and Butterﬁeld, A. (2017). Ambient and laboratory evaluation of a low-cost particulate matter sensor. Environmental Pollution, 221:491–500.

[73] Kinney, P. et al. (2003). Zigbee technology: Wireless control that simply works. In Communications Design Conference, volume 2, pages 1–7.

[74] Koponen., L. (2015). Raspberry Pi controller. http://rpc.gehennom.org/. Accessed on 6 April 2019.

[75] Krishnan, S. and Gonzalez, J. L. U. (2015). Building Your Next Big Thing with Google Cloud Platform: A Guide for Developers and Enterprise Architects. Springer.

[76] Kumar, P., Morawska, L., Martani, C., Biskos, G., Neophytou, M., Di Sabatino, S., Bell, M., Norford, L., and Britter, R. (2015). The rise of low-cost sensing for managing air pollution in cities. Environment International, 75:199–205.

[77] Kumar, S., Gil, S., Katabi, D., and Rus, D. (2014). Accurate indoor localization with zero start-up cost. In Proceedings of the 20th Annual International Conference on Mobile computing and networking, pages 483–494. ACM.

[78] Lashof, D. A. and Ahuja, D. R. (1990). Relative contributions of greenhouse gas emissions to global warming. Nature, 344(6266):529–531. REFERENCES 125

[79] Lechelt, Z., Rogers, Y., Marquardt, N., and Shum, V. (2016). ConnectUs: A New Toolkit for Teaching about the Internet of Things. In Proceedings of the 2016 CHI Conference Extended Abstracts on Human Factors in Computing Systems, pages 3711– 3714. ACM.

[80] Lee, J. H., Hancock, M. G., and Hu, M.-C. (2014). Towards an eﬀective framework for building smart cities: Lessons from Seoul and San Francisco. Technological Forecasting and Social Change, 89:80–99.

[81] Lekić, M. and Gardašević, G. (2018). IoT sensor integration to Node-RED platform. In 2018 17th International Symposium INFOTEH-JAHORINA (INFOTEH), pages 1– 5. IEEE.

[82] Levis, P., Madden, S., Polastre, J., Szewczyk, R., Whitehouse, K., Woo, A., Gay, D., Hill, J., Welsh, M., Brewer, E., et al. (2005). TinyOS: An operating system for sensor networks. In Ambient Intelligence, pages 115–148. Springer.

[83] Lewis, A. C., Lee, J. D., Edwards, P. M., Shaw, M. D., Evans, M. J., Moller, S. J., Smith, K. R., Buckley, J. W., Ellis, M., Gillot, S. R., et al. (2016). Evaluating the performance of low cost chemical sensors for air pollution research. Faraday discussions, 189:85–103.

[84] Li, Y. and Manoharan, S. (2013). A performance comparison of SQL and NoSQL databases. In Communications, Computers and Signal Processing (PACRIM), 2013 IEEE Paciﬁc Rim Conference on, pages 15–19. IEEE.

[85] Libelium (2016). Mobile monitoring system: Vehicles with sensors to control air quality in Glasgow. http://www.libelium.com/mobile-monitoring-system- vehicles-with-sensors-to-control-air-quality-in-glasgow/. Accessed on 30 March 2019.

[86] Libelium (2017a). Smart City project in Ljubljana Shopping and Business Centre to follow its Green Mission strategy. http://www.libelium.com/smart-city-project- in-ljubljana-shopping-and-business-centre-to-follow-its-green-mission- strategy/. Accessed on 30 March 2019.

[87] Libelium (2017b). Snow and ice monitoring in UK winter highways for a Smart Road management. http://www.libelium.com/snow-and-ice-monitoring-in-uk- winter-highways-for-a-smart-road-management/. Accessed on 30 March 2019.

[88] Libelium Comunicaciones Distribuidas S.L (2017). Libelium. http:// www.libelium.com/. Accessed on 30 March 2019.

[89] Liu, H., Darabi, H., Banerjee, P., and Liu, J. (2007). Survey of wireless indoor positioning techniques and systems. Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on, 37(6):1067–1080. 126 REFERENCES

[90] Ltd., R. P. T. (2019). ADD-ON BOARDS AND HATs. Online at https: // github .com/ raspberrypi/ hats . Accessed on 11 April 2019.

[91] M. Kurtzer, G. (2016). Singularity 2.1.2 - Linux application and environment containers for science. 10.5281/zenodo.60736.

[92] Madhavapeddy, A. and Scott, D. J. (2013). Unikernels: Rise of the virtual library operating system. Queue, 11(11):30.

[93] Manolakis, D. E. (1996). Eﬃcient solution and performance analysis of 3-D position estimation by trilateration. Aerospace and Electronic Systems, IEEE Transactions, pages 1239–1248.

[94] Mariakakis, A. T., Sen, S., Lee, J., and Kim, K. (2014). Sail: Single access point- based indoor localization. In Proceedings of the 12th annual international conference on Mobile systems, applications, and services, pages 315–328. ACM.

[95] Marksteiner, S., Jiménez, V. J. E., Valiant, H., and Zeiner, H. (2017). An overview of wireless IoT protocol security in the smart home domain. In 2017 Internet of Things Business Models, Users, and Networks, pages 1–8. IEEE.

[96] Maxwell, Jake and Purnell, Newley (2016). Singapore Is Taking the ‘Smart City’ to a Whole New Level. https://www.wsj.com/articles/singapore-is-taking-the- smart-city-to-a-whole-new-level-1461550026. Accessed on 4 April 2019.

[97] Mayer, H. (1999). Air pollution in cities. Atmospheric environment, 33(24):4029– 4037.

[98] Meﬀert, C., Clark, D., Baggili, I., and Breitinger, F. (2017). Forensic State Acquisi- tion from Internet of Things (FSAIoT): A general framework and practical approach for IoT forensics through IoT device state acquisition. In Proceedings of the 12th International Conference on Availability, Reliability and Security, page 56. ACM.

[99] Mender (2017). Over-the-air software updates for embedded Linux devices. https: //mender.io/. Accessed on 26 April 2019.

[100] Merkel, D. (2014). Docker: lightweight Linux containers for consistent development and deployment. Linux Journal, 2014(239):2.

[101] Miorandi, D., Sicari, S., De Pellegrini, F., and Chlamtac, I. (2012). Internet of things: Vision, applications and research challenges. Ad Hoc Networks, 10(7):1497– 1516.

[102] Mishra, S. and Beaulieu, A. (2004). Mastering Oracle SQL: Putting Oracle SQL to Work. O’Reilly Media, Inc.

[103] Mocevicius, R. (2015). CoreOS Essentials. Packt Publishing Ltd. REFERENCES 127

[104] Momjian, B. (2001). PostgreSQL: Introduction and Concepts, volume 192. Addison- Wesley New York.

[105] Mora, L. and Bolici, R. (2015). How to become a smart city: Learning from amsterdam. In International conference on Smart and Sustainable Planning for Cities and Regions, pages 251–266. Springer.

[106] Moran, D., Bychkov, E., Sherman, I., and Ron, U. (2013). Foldable mobile phone. US Patent 8,406,826.

[107] Nahrstedt, K., Lopresti, D., Zorn, B., Drobnis, A. W., Mynatt, B., Patel, S., and Wright, H. V. (2016). Smart Communities Internet of Things. arXiv preprint arXiv:1604.02028.

[108] Nasar, M. and Kausar, M. A. (2019). Suitability Of Inﬂuxdb Database For Iot Ap- plications. International Journal of Innovative Technology and Exploring Engineering, 8(10):1850–1857.

[109] Negus, C. (2015). Docker Containers (includes Content Update Program): Build and Deploy with Kubernetes, Flannel, Cockpit, and Atomic. Prentice Hall Press.

[110] Nijholt, A. (2008). Google home: Experience, support and re-experience of social home activities. Information Sciences, 178(3):612–630.

[111] Ono, T., Lida, K., and Yamazaki, S. (2017). Achieving sustainable development goals (SDGs) through ICT services. FUJITSU Sci. Tech. J, 53(6):17–22.

[112] Open Data Institute (2016). Breathe Heathrow: Democratising air data to meet local needs. http://theodi.org/summer-showcase-breathe-heathrow. Accessed on 4 April 2019.

[113] OpenStreetMap Contributors (2019). OpenStreetMap.

[114] Pfeil, M., Bartoschek, T., and Wirwahn, J. A. (2015). OPENSENSEMAP-A Cit- izen Science Platform For Publishing And Exploring Sensor Data as Open Data. In Free and Open Source Software for Geospatial (FOSS4G) Conference Proceedings, volume 15, page 39.

[115] Platform for Accelerating the Circular Economy (PACE) and the UN E-Waste Coalition (2019). A New Circular Vision for Electronics. Online.

[116] Plotly (2016). Plotly. https://plot.ly/. Accessed on 1 May 2019.

[117] Poulter, A. J., Johnston, S. J., and Cox, S. J. (2016). SRUP: The secure remote update protocol. In Internet of Things (WF-IoT), 2016 IEEE 3rd World Forum on, pages 42–47. IEEE.

[118] Prometheus (2016). Prometheus. https://prometheus.io/. Accessed on 26 April 2019. 128 REFERENCES

[119] Purington, A., Taft, J. G., Sannon, S., Bazarova, N. N., and Taylor, S. H. (2017). Alexa is my new BFF: social roles, user satisfaction, and personiﬁcation of the amazon echo. In Proceedings of the 2017 CHI Conference Extended Abstracts on Human Factors in Computing Systems, pages 2853–2859. ACM.

[120] Rappaport, T. S. et al. (1996). Wireless communications: principles and practice, volume 2. Prentice Hall PTR New Jersey.

[121] Raymond, S. A., Gordon, G. E., and Singer, D. B. (1998). Health monitoring system. US Patent 5,778,882.

[122] Recupero, D. R., Presutti, V., Consoli, S., Gangemi, A., and Nuzzolese, A. G. (2015). Sentilo: frame-based sentiment analysis. Cognitive Computation, 7(2):211– 225.

[123] rkt (2017). rkt. https://github.com/rkt/rkt. Accessed on 26 April 2019.

[124] Roberts, S., Arseneault, L., Barratt, B., Beevers, S., Danese, A., Odgers, C. L., Moﬃtt, T. E., Reuben, A., Kelly, F. J., and Fisher, H. L. (2019). Exploration of NO2 and PM2. 5 air pollution and mental health problems using high-resolution data in London-based children from a UK longitudinal cohort study. Psychiatry research, 272:8–17.

[125] Salvador, O. and Angolini, D. (2014). Embedded Linux Development with Yocto Project. Packt Publishing Ltd.

[126] Samteladze, N. and Christensen, K. (2012). Delta: Delta encoding for less traﬃc for apps. In 37th Annual IEEE Conference on Local Computer Networks, pages 212–215. IEEE.

[127] Sayahi, T., Butterﬁeld, A., and Kelly, K. (2019). Long-term ﬁeld evaluation of the plantower pms low-cost particulate matter sensors. Environmental pollution, 245:932– 940.

[128] Schwab, K. (2015). The Fourth Industrial Revolution: what it means and how to respond. World Economic Forum.

[129] Scuro, C., Sciammarella, P. F., Lamonaca, F., Olivito, R. S., and Carni, D. L. (2018). IoT for structural health monitoring. IEEE Instrumentation & Measurement Magazine, 21(6):4–14.

[130] Seaton, A., Godden, D., MacNee, W., and Donaldson, K. (1995). Particulate air pollution and acute health eﬀects. The lancet, 345(8943):176–178.

[131] seed (2017). Grove System. http://wiki.seeed.cc/Grove_System/. Accessed on 27 April 2019. REFERENCES 129

[132] Shacklette, M. (1995). Linux Operating System. Handbook of Computer Networks: LANs, MANs, WANs, the Internet, and Global, Cellular, and Wireless Networks, Volume 2, pages 78–90.

[133] Shchekotov, M. (2014). Indoor localization method based on Wi-Fi trilateration technique. In Proceeding of the 16th conference of fruct association.

[134] Sigoure, B. (2010). OpenTSDB: The distributed, scalable time series database. Proc. OSCON, 11.

[135] Singh, R., Gehlot, A., Gupta, L. R., Singh, B., and Swain, M. (2019). Internet of Things with Raspberry Pi and Arduino.

[136] Southern Water (2017). Your AMR meter. https://www.southernwater.co.uk/ your-amr-meter. Accessed on 30 March 2019.

[137] spybike (2014). Anti-theft GPS tracking devices for Bicycles. http:// www.integratedtrackers.com/. Accessed on 11 April 2019.

[138] Stackowiak, R. (2019). IoT Central and Solution Accelerators. In Azure Internet of Things Revealed, pages 119–143. Springer.

[139] SWupdate (2010). SWupdate. Online. https://github.com/sbabic/swupdate. Accessed on 26 April 2019.

[140] The Freecycle Network (2017). Freecycle UK. https://www.freecycle.org/. Ac- cessed on 31 March 2019.

[141] The Open Knowledge Lab (2017). Fine Dust Sensor for Citizen Science Project. http://luftdaten.info/. Accessed on 27 April 2019.

[142] The Things Network (2017). The Things Network. https:// www.thethingsnetwork.org/. Accessed on 28 April 2019.

[143] TP-Link (2017). 2.4GHz 5dBi Indoor Omni-directional Antenna. Technical report.

[144] Turnbull, J. (2014). The Docker Book: Containerization is the new virtualization. James Turnbull.

[145] Vangelista, L., Zanella, A., and Zorzi, M. (2015). Long-range IoT technologies: The dawn of LoRa. In Future Access Enablers of Ubiquitous and Intelligent Infrastructures, pages 51–58. Springer.

[146] Vasisht, D., Kumar, S., and Katabi, D. (2016). Decimeter-level localization with a single WiFi access point. In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pages 165–178. 130 REFERENCES

[147] Vavilapalli, V. K., Murthy, A. C., Douglas, C., Agarwal, S., Konar, M., Evans, R., Graves, T., Lowe, J., Shah, H., Seth, S., et al. (2013). Apache Hadoop yarn: Yet another resource negotiator. In Proceedings of the 4th annual Symposium on Cloud Computing, page 5. ACM.

[148] Velosa, A., Schulte, W. R., and Benoit, J. L. (2016). Hype cycle for the internet of things, 2016.

[149] Walters, C., Poo-Caamaño, G., and German, D. M. (2013a). The future of continuous integration in GNOME. In Proceedings of the 1st International Workshop on Release Engineering, pages 33–36. IEEE Press.

[150] Walters, C., Poo-Caamaño, G., and German, D. M. (2013b). The future of continuous integration in GNOME. In Proceedings of the 1st International Workshop on Release Engineering, pages 33–36. IEEE Press.

[151] Walton, H., Dajnak, D., Beevers, S., Williams, M., Watkiss, P., and Hunt, A. (2015). Understanding the health impacts of air pollution in London. London: Kings College London, Transport for London and the Greater London Authority.

[152] Wang, Y. and Shao, L. (2017). Understanding occupancy pattern and improving building energy eﬃciency through Wi-Fi based indoor positioning. Building and Environment, 114:106–117.

[153] Weiser, M. (1991). The computer for the 21st century. Scientiﬁc American, 265(3):94–104.

[154] Weiser, M. (1993). Some computer science issues in ubiquitous computing. Com- munications of the ACM, 36(7):75–84.

[155] Wick, A. (2012). The HaLVM: A simple platform for simple platforms. Xen Summit Talk, August.

[156] Wilder, B. (2012). Cloud architecture patterns: using Microsoft Azure. O’Reilly Media, Inc.

[157] World Health Organization (2006). Air quality guidelines: global update 2005: particulate matter, ozone, nitrogen dioxide, and sulfur dioxide. World Health Organi- zation.

[158] Yadav, V. and Yadav, V. (2015). Challenging and oppourtunities of Project Ara. IT INTELLIGENCE INNOVATIONS-2015, page 1.

[159] Zuniga, J. C. and Ponsard, B. (2016). Sigfox system description. LPWAN@ IETF97, Nov. 14th, 25.