Monsieur Nazim Agoulmine Professeur

Universite D'evry-Val-D'essonne

Rapporteur Monsieur

Norbert Noury Professeur

Président Monsieur Universite Lyon

Gregory Blokkeel Docteur-Ingenieur

Psa Groupe

Examinateur Singapour

Keywords: semantic web, quantified self, mobility, activity recognition, rule-based reasoning i web sémantique, soi quantifié, mobilité, reconnaissance d'activité, raisonnement à base de règles iii SQL Structured Query Language. 83 SSH Secure Shell. 81 SVM Support Vector Machines. 39 architecture .

Connected objects of everyday living have made their way into our lives. Known as Internet of Things, the various technologies inspire a vast variety of applications. One of the pioneer applications is the concept and development of a smart home. This is now spreading outdoors; making vehicles, buildings, and even large cities smart. Moreover, the technology is getting more personal as well -as wearing smart clothes and other self-tracking devices become increasingly common and popular. This is often referred to as the quantified self.

One particular case of a smart environment is ambient assisted living, which is designed to enhance elderly people's day-to-day life. Such a ubiquitous and unobtrusive computer system can also be ported to other domains and age groups. For instance, the tracking of daily activities can also help younger adults to improve their lifestyle. Everyone can be encouraged to maintain a healthy lifestyle, perform sufficient physical activity, and make more informed decisions about their mobility. These are direct factors in preventing health risks, such as metabolic diseases like the type 2 diabetes, and allow a better control over respiratory diseases like the asthma.

Driven by these ideas, this thesis explores the possibilities of a web-based platform with a semantic rule-based reasoning. The thesis details the work on technical improvements, enhancements in activity recognition, extensions for data analysis, and a mobility-oriented application.

Following a user-centric approach, a real life deployment of the described technologies is necessary. Two use cases are examined. First, I enhanced and built upon a pre-existing system, which consists of sensors and a gateway placed into elderly participants' homes. The second use case is the deployment of a mobile phone application for active mobility assistance. Collecting relevant and timely data, the application then outputs a level of recommendation for every type of mobility. The recommendations are based on each user's exercise tracking device, which incorporates their goals, their profile, and other publicly available data sources such as weather and air quality in user's surroundings. This thesis describes the outcomes and lessons learnt from these deployments. In addition, this thesis provides an in-depth discussion as well as analytical insights on the results of the deployments.

Introduction

We are living in the age of information and digital technology. As digital technologies continue to permeate into every aspect of our lives, information and data collection increase in material and emotional values. Today, computation is at the core of many daily essential services, powering simple systems such as traffic lights on the roads all over the world to complex banking and financial services on the Internet. For many people, having personal pocket computer such as the smartphone or a tablet has become a necessity, even though such technology would have been unimaginable 20 years ago. To attain a simple weather forecast, a service that some might have taken for granted, it actually requires the power of computer clusters and complex models.

Responsible use of digital technologies can contribute positively to our human society, such as capitalising on information to enhance people's quality of life. Digital environments offer an overwhelming multitude of tools to observe and evolve our physical environments. Mastering these technologies goes beyond technical proficiency; usage of the tools also necessitates a high level of personal responsibility.

As digital technologies become more intrusive, there are increasing concerns about one's privacy and security. To meet these concerns, we are beginning to see the creation of new legislative measures and regulatory policies. Their increasing complexities mean that some of the regulations may be difficult to abide by. When modern modes of transportation developed over the past two hundred years, governments implemented traffic rules to manage chaos and accidents on the roads. In a similar fashion, there is a need for regulations in the thriving realm of digital technologies, even those that serve our homes, the outdoors, or in our pockets. The challenge is to simplify and optimise new applications, and at the same time respect and abide by complex laws and regulations.

This thesis posits that it is possible to design new applications that can improve lives, while maintaining a keen awareness of possible negative impacts. In fact, concerns can be taken into account and addressed effectively.

The thesis describes processes and contributions to a software system oriented towards well-being. The system that I helped to shape is meant to improve the quality of life of its users. It treats two distinct cases. In one case, it helps elderly people to feel safer, and in another, it encourages the active mobility with respect to the current situation.

For first case focused on elderly people, the system is used without any interaction from the monitored participants. On the other side, their caregivers are provided with simple interfaces. In this way the caregivers can observe that everything is going well or detect potential irregularities and take action.

The case of mobility enhancements was developed in collaboration with our industrial partner, PSA Group. the system provides a gateway to the public data, connects it and makes sensible recommendations of a mobility solution. This system is verifiable as the decision process is completely transparent. In fact, adherence to medical advice, and active mobility in particular, can make considerable differences in one's quality of life. This is why the research in active mobility addressing the chronic diseases issue could be viewed as a complementary extension of the Ambient Assisted Living (AAL) research and elderly care.

Wider Context of the Thesis

Computer science connects scientific disciplines, and provides a framework for creation or simulation, analysis, and validation of various systems. From this angle, this work approaches the question of how quality of life can be improved. I use first order logic within software engineering to create a working system that answers to the identified users' needs. Specifically, I incorporate hardware components, as well as software techniques for information processing, and provide an adapted humanreadable output. All together, this creates a system of an artificial intelligence that is fully understood and focused on the needs of modern and ageing societies.

Wider Context of the Thesis

Making technologies work is a process that is seemingly getting easier as ready-made solutions become freely available. However the problem might have shifted to the choice of the best solution. More and mode people join open source communities1 , contribute and share their code. As the software development becomes more widespread, automation and home-improvement have a special place. The popularity of smart homes is fuelled by an increasing accessibility of physical components (sensors, actuators), as well as by increasing accessibility of online manuals, shared experiences and software recipes.

From a scientific point of view, the current situation can be seen as a golden age for data collection. Data can be processed, analysed and used in order to enhance the quality of life. However, many questions arise when dealing with data: What data do we collect? How do we do it? Is the data trustworthy? How do we process it? What is the use case? What are the consequences of a mistake? Is the system correct?

Internet of Things (IoT) is a powerful concept of connecting objects of everyday life in an interconnected network. Rightfully, it generates security concerns, which may overshadow its potential and functionality. The right implementation of this concept has to balance the user's convenience and security, along with user's own perceptions of both.

The aim of this thesis is, through projects it contributed to, to assist elderly people, and to people with chronic diseases (e.g. type 2 diabetes, asthma). It is oriented on people's well-being. For the elderly, it aims to help them to retain their independence for as long as possible. For younger people, the intention is to enhance the active mobility that helps managing chronic diseases and therefore the overall quality of life (current and future).

These high-level objectives of increasing people's quality of life, translate into scientific challenges through a segmentation of the problem at hand. First, context awareness is supposed to answer the following questions: (i) what is the situation our user is facing?; (ii) in which environment are they in?; (iii) what are the parameters, including the profile of the user, other real-time and historic data about the user (trends in physical activity or preferred mobility) and relevant information for the purpose of the system (weather conditions, actual transport data conditions and availability). Second, context is very much linked to the evaluation of the situation that the system detected. This is the core problem involving reasoning process that may or may not mimic a human way of thinking.

Last, the user interface -all the information that the system compiles has to have an output, and impact on the outside of the system. As for enhancing someone's quality of life and well-being, and making them more autonomous, the system's interface and intervention system has to be carefully designed and tested. In the case of an elderly participant, this might require a feedback loop including potential caregivers and relatives. In terms of personalised mobility solutions, a mobile application interface was designed, providing notifications, gamification elements, concise information about context, as well as the results of mobility assessment, and recommendations.

As part of the project with PSA Group, this thesis, addresses the problems related to the ageing population and chronic diseases in the global population. The research aims to deal with issues of frailty and enhance the quality of life, by focusing on wellbeing and mobility. Following sections will cover aspects that drive and influence the research presented in this thesis.

Demographic Issues

Contributions of the thesis continue the efforts of City4Age project (section 6.3.1) in elderly people's monitoring that provide outputs to.

Ageing is a global issue. All regions in the world face the issue of ageing populations, as confirmed by the most recent revision of United Nations (UN) report on World Population Prospects [United Nations 2017]. Good health care provisions for our elderly people yielded to an unexpected downside: an ageing society. This phenomenon makes the population realise that a longer life can be enjoyed more in good health. It creates a motivation to actively seek options to extend a good health condition, which might be combined with a possibility to stay economically active for as long as it is possible. Independence in life is a very crucial aspect contributing to one's personal dignity contributing to the overall quality of life.

As [Bryant et al. 2017] posits, next 20 years bring a global demographic shift from predominantly younger populations to older ones. "The shifting age average will make obsolete the current models of health care and elderly care. They will need to be adapted and updated to become more citizen-focused. They will need to support greater community resilience and sustainability. New approaches will be required for innovation and information technologies to improve quality of life for people as they age, by reducing the onset of frailty as well as providing better support for those with long term conditions. This can be done through the employment of self-management and prevention strategies." Following the trends in developed countries, in Singapore, residents aged 65 years and over formed 13.7 % of the resident population in 2018, a rise from 11. Published by the UN, the 2017 revision of the report (the last revision as of August 2019), confirms the trend of ageing and makes predictions for next 30 years. Figure 2 shows predictions of the population aged 60 years or more. It illustrates that the largest proportional increase is expected from less developed countries, excluding the least developed countries. As of 2017, 13 % of the global population is aged 60 or over. Europe stands out with the highest percentage of 25 %.

Chronic Diseases

An area targeted by the thesis is a management of chronic diseases. In this section, I will explain which diseases are of interest and what can help to keep them under control. The section will focus on the environment and data related to Singapore as it is the place where the experimentations are being carried out.

With early diagnostics, it is possible to discover chronic diseases before they cause 1.4 Chronic Diseases serious impacts on our lives. With an appropriate change in the lifestyle, they can be managed to minimise the negative impact on one's quality of life. In practice, adherence to medical advice, and active mobility in particular can make considerable differences.

The thesis contributions align with PULSE project (section 6.3.2) and focus on type 2 diabetes and asthma.

Diabetes mellitus, commonly known as diabetes, is a chronic disease, which occurs when the pancreas does not produce enough insulin, or when the body cannot effectively use the insulin it produces. This leads to an increased concentration of glucose in the blood, hyperglycaemia.

• Type 1 diabetes (previously known as insulin-dependent or childhood-onset diabetes) is characterised by a lack of insulin production;

• Type 2 diabetes (formerly called non-insulin-dependent or adult-onset diabetes) is caused by the body's ineffective use of insulin. It often results from excess body weight and physical inactivity. Being a chronic illness, it lasts for years or is lifelong. Its treatment consists of self-care and anti-diabetic medications. It can be prevented or delayed with early lifestyle changes. People with pre-diabetes can reduce their risk by increasing their physical activity, eating healthily and losing weight (if they are overweight); and

• Gestational diabetes is hyperglycaemia that is first recognised during pregnancy.

The comparison of government open data and national prevalence values extracted from 8 International Diabetes Federation (IDF) Diabetes Atlas reports are presented in fig. 3.

In Singapore, the diabetes mellitus prevalence amongst the adult population (aged 20 to 79) is at alarming 13.7 % [IDF 2017]. The figures vary depending on the diagnosis criteria and age groups. Newspapers report comparative ranking as in [Lai 2015], Singapore has the second highest rate in developed countries as of 2015.

The government open data reports prevalence of 8.3 % in 2010 and 8.6 % in 2017 (the most recent as of the current date). These rates differ from previously mentioned data due to following: lower age, 18 to 69, and the inclusion condition: Fasting plasma glucose ≥ 6.9 mmol/l. IDF reports take into account an older age group, 20 to 79, where the occurrence of diabetes increases significantly. Their definition of diabetes also encompasses any of these conditions: Fasting plasma glucose ≥ 7.0 mmol/L (126 mg/dL) or two-hour plasma glucose ≥ 11.1 mmol/L (200 mg/dL) following a 75g oral glucose load or A random glucose > 11.1 mmol/L (200 mg/ dL) or HbA1c ≥ 48 mmol/mol (equivalent to 6.5%). As reported by Straits Times newspaper [START_REF] Lai | Singapore risks hitting obesity rates of 15% in seven years[END_REF]], a Singapore Health Promotion Board (HPB) study, which tracked more than 60 000 Singaporeans starting in 1990 -following some participants from childhood through the time they started work -found that Singaporeans, on average, are 3 kg heavier today than they were 15 years ago, more likely to overeat and tend to put on weight once they enter the workforce. The primary contributing factors, researchers found, are a decrease in physical activity and increase in calorie intake.

Asthma is a chronic disease characterised by recurrent attacks of breathlessness and wheezing, which vary in severity and frequency from person to person. Symptoms may occur several times in a day or week in the affected individuals, and some people may experience worse symptoms during physical activities or in the night time. Although asthma cannot be cured, appropriate management can help to control the disease and enable people to enjoy a good quality of life.

As a contributing factor, Singapore has been regularly hit by smoke haze from forest fires in nearby Sumatra, Indonesia, brought over by wind. These forest fires have been attributed to the slash-and-burn method favoured by several large plantation owners to clear their land, as opposed to a more expensive and inconvenient mechanical approach using excavators and bulldozers. In June 2013, severe haze hit Singapore, pushing the nation's Polluant Standards Index (PSI) into levels considered "hazardous" for the first time in its history.

Each individual's reaction to pollutants may vary, and the amount of physical activity or exertion that can be performed differs according to one's health status or 1.5 Interest in Technology physical capacity.

Interest in Technology

The aforementioned topic regarding quality of life can be tackled in different ways.

It may make use of commercial sensors, smart homes, connected cars, smartphones, wearable sensors, or even implants. As long as we use some kind of mechanism that has a physical element involved, there can be a technological solution. Current evolution of the electronics and digital technologies in particular allows us to abstract the hardware layer to a certain level and get closer to conceptual solutions. The design of the physical-impact system moved to virtual environments (computer-aided design). In these systems, the designer manipulates pre-conceived and generalised concepts. The same process is being applied on the generation of computer systems. Design patterns for the construction of such a system are inspired by physical, mechanical, biological, chemical or even administration systems. Naturally, the vast quantity of options to design a system creates the problem of the choice, and this itself becomes a problem. This type of problem is being addressed in theoretical sciences. Game theory, optimisation algorithms, and formal verification can be used to assess and orient the design, development and evolution of a system.

Tools offered by different fields, tools that answer partial problems, provide a solid and essential base for creation of new systems. Their interconnection has a potential to create more powerful technologies to answer further questions. The smart home, the Internet of Things (IoT), the 5G, the concept of connected car and other smart environments and objects can be parts of the solution to our problems.

Impact of Internet of Things & 5G

Recent emergence of the Internet of Things has created interesting opportunities, in addition to important questions about security and privacy. It offers technical challenges for embedded systems in small devices and challenges for models in networking, as the massive amount of devices will impact the performances of network equipment and protocols that were not designed to support these use cases.

The 5G as a new generation of mobile technologies must be taken into account when considering the technological solutions. Evaluation of its potential is the main reason of its inclusion within this thesis. Wireless networks represent the fundamental technology that allows us to provide services. Their evolution is an inseparable part of the technological landscape.

Internet of Things

While the Internet was created as the interconnection of computer networks, the term "Internet of Things" emphasises that all sorts of objects can be enabled to join the network and communicate with one another.

IoT also refers to the manufacturing explosion of network-enabled objects with all pros and cons. Basically, objects of our everyday life are connected to the global network and by extension, they are also accessible on the Internet. Currently, we have seen watches, light bulbs, motion sensors, refrigerators, toys, electrical switches, heaters, and even cars being part of the IoT network.

Frequently, the objects with such a capability are referred to as "smart". The use of this term is partly justified by the fact that the "smartness" of the object's behaviour is not necessarily situated within its physical body. A robotic toy can perform "smart" interactions, by having just sensors, actuators and a communication module. Then, the processing of the sensor signal and deciding what actuator should do can be decided anywhere. The toy is only a "terminal" in the terminology of early computers as illustrated in fig. 4. The same architecture is used for massively accessed applications where a mainframe computer provides services to "thin" clients (terminals). In this sense, "thin" client means that the physical machine of a client does not need high processing power to provide the service of the mainframe computer (supercomputer). The shift in this paradigm was marked by development of the "personal computer", or PC, when computing power was concentrated into a single machine. This paradigm of a mainframe and a terminal emerged again, for example, with Chromebooks, where the machine provides the processing power but the data storage is in the cloud.

Cloud A computation resources provided as a service ease the conception of ubiquitous applications. The service abstracting a geographically located physical machine is referred to as a "cloud", "cloud computing" or computing "in the cloud". This term "cloud" metaphorically represents something remote, composed of many particles, form-shifting, opaque, and untouchable however visible from afar. This service allows the software developer to access the content and remotely use a machine from anywhere as long as there is an Internet connection. The service provider provides a user interface for interaction with the computer; either a dedicated physical machine or a "virtual" machine. A virtual machine is a simulated environment that performs in the same way as the target system. Also, appropriate resource management makes it possible to simulate more than one virtual machines in one physical machine. The advantage for software developers is the ability to select the hardware configuration adapted to their needs -or change it at much lower cost than buying the actual hardware. The ease of access to this service is one of the pillars of the Internet of Security concerns in IoT Connectivity and cloud computing create a great potential for innovation. However, insecure implementations of these blocks or the connection between them can easily compromise the whole solution. There are four different weaknesses: the object itself, the transmission towards the processing computer, the processing computer itself (potentially in the cloud), and the user.

Device vulnerability: First, the object itself is prone to security issues. A connected light bulb will have diametrically different computation power than a connected car. One is physically protected from physical access in your home, while the other is publicly parked. The reasons behind the different computation power are the cost, space, and use. The manufacturers have to create a viable product in economical terms. Even if security is one of the most appreciated properties of a product, the market does not always favour it. To create a successful product, the manufacturer has to develop it quickly, with a maximum number of features, provide security features, guarantee safe operation (no health risks), and ensure a competitive price and size. Making things smaller and cheaper means potentially less computational power and therefore leaving less possibilities to implement a proper cryptographic protocols and interfaces. Some devices provide a console access (cameras, network routers, and toys such as Karotz) that was enabled for debugging.

If accessible on a port exposed on a Wi-Fi network or via Bluetooth, it can be exploited by a malicious attacker, effectively compromising the device.

Transmission vulnerability:

The second weakness is the transmission, when the data (or commands) travel through networks to a different equipment. This is where the implementation of the protocol is important. Several protocols have been created to answer the call of the IoT, and the most popular ones are Zigbee and Z-Wave. In [START_REF] Mahadewa | [END_REF], cases of Philips Hue light bulb, LIFX lighting system and Chromecast computer to TV screen transmission are discussed. An insufficient implementation may give rights to unauthorised users, or leak the content's meta data. They can also be vulnerable to a replay attack, when a captured communication can be used to authenticate an unauthorised access (e.g. transmission of a plain password compromises the system because anyone who could read it can use it).

Processing machine vulnerability: Third, on the processing end, the computer could be compromised by a weakness in the system running on the machine, such as exploits of PHP Content Management System (CMS), like Wordpress or Drupal. Another risk might be linked to the virtualisation as described earlier in this subsection. The hosting computer simulating multiple machines may allow cross-machine access in some very special cases. An example can be a vulnerability VENOM in certain emulators [Geffner 2015].

User vulnerability:

The part of the system that is not under system designer's control is the user. Even if the system is perfectly designed, the user's ignorance of the safety procedures can make the whole chain vulnerable. For example, not changing the default passwords can lead to make the device an easy acquisition for botnets. A botnet is a network of compromised devices that execute any arbitrary code sent by the attacker. For instance, in late 2016, the botnet nicknamed "Mirai" comprised of more than 200, 000 IoT devices, managed to take down several wellknown services on the Internet. The affected web services include Amazon, OVH, the micro-blog platform Twitter, and the video-on-demand service Netflix. 36 % of the infected devices were identified as IP video cameras and the main attack vector was the use of default passwords. From a technical point of view, the user neglected the security. However, on the usability point of view, it is easy to make the product operate only after a strong password has been properly set.

Security breaches

Connected light bulbs and other simple objects received a lot of attention when cybersecurity research found their vulnerabilities. [START_REF] Mahadewa | [END_REF]] presents a semi-automatic system for analysis of the security of smart home devices. Many algorithms were developed to address the need for lightweight and secure protocols. (These were listed in [Surendran et al. 2018] 3DES, AES, Blowfish, DES, DESL, DESX, DESXL, Katan & Ktantan, HIGHT, HIGHT2, Hummingbird, Hummingbird-2, KEELOQ, LBLOCK, LED, mCrypton, NOEKEON, PES, PRESENT, RC2, RC6, RSA, SEA, Skipjack, Simon and Speck, TEA, XTEA and TWINE).

Connected Vehicles

Becoming part of the smart cities, connected vehicles are supposed to enhance the quality of life in urban areas. Therefore, they are a part of the picture that this thesis needs to take into account.

On top of providing rapid personal transportation, an ordinary car has other significant functions. It is also a private space and could almost be seen as a "second home" for the individual. The car not only offers privacy, but also protection and entertainment. It shields the riders from rain, filters the air, while offering navigation and infotainment systems. Essentially, the car is an ecosystem that attempts to provide in a confined space everything we need. As a part of the connected world of IoT, connected cars form a special category and provide an interesting support for the extension of a smart home concept outdoors, featuring a support for high computational power. Advances in data processing and underlying hardware opened a path to the massive emergence of driverless cars development. Envisioned levels of autonomy are illustrated in fig. 5. The communication between the vehicle and other entities is also highlighted:

• V2I "Vehicle to Infrastructure": The communication between the infrastructure and the vehicle contains information about road conditions and the perceptions that were collected by the vehicle.

• V2V "Vehicle to Vehicle": Information about other vehicles, includes vehicles' speed and position for accident avoidance and traffic fluidity.

• V2C "Vehicle to Cloud": Exchange of information with remote services. For example, entertainment, news or smart home.

• V2P "Vehicle to Pedestrian": Exchanging information about the environment surrounding the vehicles and the pedestrians through personal mobile devices.

• V2X "Vehicle to Everything": Information exchange that encompasses all vehicles and objects.

The connected car (connected vehicle), appears to require a considerable amount of data to be exchanged. New network types are envisioned and in particular, two technologies compete: Wi-Fi and 5G. The Wi-Fi is well established in terms of industrial and home applications. The 5G is a new technology that succeeds the 4th generation of mobile networks.

"5G" -Fifth Generation Mobile Network

Mobile telecommunications have gradually become an integral part of people's lives2 . They have a great potential for bringing more added value. In this section, I summarise the recent evolution and its meaning for quality of life.

Making a phone call from almost anywhere in the world has become a norm. At the same time, services and devices are evolving. In particular, the mobile data transmission service is the crucial part of the carriers' offer. Amongst devices, the current "smartphone" is, in fact, a pocket-sized personal computer with phone call service. Higher throughput, or "speed", meaning more bytes transmitted per second, helps to meet two often contradictory demands: convenience and security. Users' convenience demands higher speed, e.g. higher resolution video stream. At the same time, security and privacy concerns can also be addressed by making use of higher speed. More available data means that the communication can use higher encryption and even steganography to secure the transmission. A more reliable and faster internet connection are the main promises of the "5G".

Figure 6: Mobile network generations from 1G to 5G, source [Fizza & Shah 2015] History of Mobile Network Generations 1G Illustrated in fig. 6, the history of the mobile phone started in 1980s with 1G, the first generation. An alternative term for a mobile phone, cell phone refers to the division of the land into areas covered by a telecommunication tower -cells. The frequencies spectrum was divided in channels with large gaps in-between to avoid interference. This limited the number of users as one call would occupy the full channel. The 1G devices were heavy and expensive.

2G

The second generation marked the 1990s. It included text messages via short messaging service (SMS) and even early data transfers. 2G improved the accessibility of the service to more users with compression and multiplexing, allowing more than one user per channel. The most popular standard implemented in 1990's, Global System for Mobile Communications (GSM), allows 8 users per channel. The data transfer was enabled by service General Packet Radio Service (GPRS) with a throughput of 54 to 114 kbps in 2000's, succeeded by Enhanced Data rates for GSM Evolution (EDGE) reaching up to 236.8 kbps. It created the possibility to send low-resolution pictures (often not more than 480 × 320) and simple audio files. The devices' development made them more portable, pocket-sized.

3G

In the 2010s, the third generation was oriented towards multimedia and web. Its digital data throughput in the basic version, similar to EDGE, up to 300 kbps and with different enhancements theoretically up to 42 Mbps. Although, in real conditions, the 3G's best performance can achieves around 8 Mbps3 . It offers the latency of 100 ms.

4G

The fourth generation enhances the throughput further to theoretical 150 Mbps (in reality 15 Mbps) limit and its enhancements, dubbed 4G+, allow theoretical transmissions up to 979 Mbps. In practice, as shown in fig. 7, in first quarter of 2019, the best experience was only around 52 Mbps in South Korea4 , and the report from August 2019 mentions 95 Mbps in Calgary, Canada. The latency is reduced to around 50 ms (fig. 8).

Arrival of the 5G

The differences are still tremendous amongst the countries, and between rural and urban areas. Geographical features, positioning indoors or outdoors, and placement of base stations, all impact the strength of signal and therefore the quality of service. The parameters that drive user experience rating are notably speed (throughput) and latency. Throughput values of the order of megabytes per second (8 Mbps) are providing a reasonable service. In common usage, currently, most of the throughput-demanding applications stream video and audio in resolution of 4K, having an expected throughput about 25 Mbps 5 .

Given the contrast between the theoretical speeds of the 4G and the real experience, it is not surprising that the 5G is welcomed with reservations. Reduced latency and high speeds, massive number of simultaneous connections are promises of the current candidate for the near future of the connectivity. These features make it very appealing for Internet of Things applications, connected cars, as well as virtual and augmented reality applications. The work on its specification started in 2012 by the ITU's Radiocommunications sector (ITU-R) and is to be finalised in 2020. This specification announces the ability of a base station to have a massive number of devices connected -1 million. The latency should be reduced to only 1 ms (expected average is 10 ms6 ). The download speeds are supposed to reach 100 Mbps (in average more than 50 Mbps).

Despite the sensational headlines of various technology websites making it sound as if 20 Gbps peak performance was going to be available for users, the 5G overview [ITU 2018] makes it clear: "The peak data rate of IMT-2020 for enhanced mobile broadband is expected to reach 10 Gbit/s. However, under certain conditions and scenarios, IMT-2020 would support up to 20 Gbit/s peak data rate. IMT-2020 would support different user-experienced data rates covering a variety of environments for enhanced Mobile Broadband. For wide area coverage cases, e.g. in urban and suburban areas, a user-experienced data rate of 100 Mbit/s is expected to be enabled.

In hotspot cases, the user-experienced data rate is expected to reach higher values (e.g. 1 Gbit/s indoor)."

Shortcomings of the "5G" 5G might not be the technology of choice for connected cars, due to the existence of a competing standard of using Wi-Fi.

Within the European Union, two groups have formed around the principal technological solutions for connected vehicles: Wi-Fi or 5G.

On one side, Wi-Fi technology is supported by Volkswagen, Renault, Toyota, Hyundai, NXP, Autotalks, and Kapsch TrafficCom. On the other side, 5G is preferred by PSA Group, Daimler, Ford, BMW, Deutsche Telekom, Ericsson, Huawei, Intel, Qualcomm, and Samsung.

The principal criticism of 5G technology is the potential issue of 5G coverageas it depends on a third party, telecommunication companies and Internet service providers. Another issue is the possible conflicts between telecommunication technology and vehicle technology. The resolution will require the automotive industry to invite telecommunication companies to weigh in.

Low-Power Networks

Compared to high-speed transmission, evolving in completely opposite direction, new connectivity options are being developed for IoT -low-power networks. For an ambient system for the monitoring of elderly people, requirements are low. The information flow does not require low latency nor high throughput for sensor data as no image or sound is being recorded or transmitted. In fact, only a few kilobytes of data per day are sufficient to convey the information about activities of a person.

As an example, consider a very data-rich configuration, 6 sensors, each transmitting every 5 minutes: a 1-byte presence value along with their 8-byte identifier, 2-byte temperature, 2-byte humidity, makes 6 × (24 × 60/5) × (1 + 8 + 2 + 2) = 22 464 bytes per day. This could be seen as an upper limit because some sensors provide much less information.

The most prominent aspect for a deployment is the battery life of the sensor. And less it transmits, less it consumes. For many sensor networks, the parameters provided by Low-Power Wide-Area Network (LPWAN) are sufficient. Many of networks label themselves as "narrowband", referring to the low data transfer rates. According to the state of the art [Sanchez-Iborra & Cano 2016], LPWAN networks achieve the highest energy efficiency when compared to other communications (e.g. Bluetooth, Wi-Fi, cellular or satellite).

The important advantage of this transmission method is that the gateway would not be needed, as the function of the gateway would be replaced by the network service provider. The downside is the dependency on service and its reliability. This technological solution was tested during the thesis and is considered perspective for simple sensors.

Impact of Artificial Intelligence

The term artificial intelligence encompasses simple human-made systems for easing everyday tasks in a clever way, including game-playing automatons or agents as well as deep complex systems for performing tasks that are natural to humans. This view, often presented in essays, omits an important part: the machines are made by humans. This means that not being able to conceive a machine that performs a task, exposes the inability to describe the task at hand. In other words, as we are not able to make a machine for the task, we do not fully understand that task. It actually may point to our own inability to understand the task or create its working model that represents a certain phenomenon. Naturally, the human mind became the object of such research as well. In reality, every living creature creates a model of how they are functioning. Although it might be very simple, often influenced by the authoritative sources (religion, ideology), the philosophy kept converging to a scientific method. The method creates ways for the validation of the models. It realises limits of each method and each model, enhancing them and liberating them from authoritative sources to independently validate the truth.

Current artificial intelligence that is the most impressive and has the most impact on people's lives creates emotion. Machine learning techniques are able to find 1.8 Thesis Contribution unexpected links as the viral beer-and-diaper correlation in sales, that was actually discovered by a simple statistical analysis of a database via SQL queries7 . Artificial intelligence now wins in games against humans that were previously difficult for machines due to the combinatorial explosion of possible next moves. Examples include chess and go. Along with clever (human) ideas about hard-coded heuristic strategies, the truly remarkable advance in the field was the concept of adversarial approach, where the computer trains by playing against itself. This training method was reused in other domains of artificial intelligence, such as image processing using neural networks.

Thesis Contribution

With a technical and practical approach, this thesis extends the care for a person from their habitation to outdoor environments. Based on technical paradigms defined by my predecessors, this thesis enriches and introduces new specific elements in the previously implemented reasoning process for AAL. The way of approaching the problem of quality of life improvement followed by this thesis is to deploy the architecture in real-life conditions, enhance it, analyse the collected data. A large part of the work is a search for technical solutions.

The work presented in this thesis was performed on the UbiSmart platform, previously developed by IPAL research team in a research collaboration. The platform's version 3, the starting point of this work, performed data collection from sensors, the data was injected in a knowledge base, then the reasoning produced an estimation of activities performed by the monitored elderly person. The output was then presented in a web interface. The UbiSmart ecosystem contains two main components: a gateway responsible for sending the events to the main server and the server itself that collects, analyses and visualises the data.

This thesis presents the enhancements of UbiSmart platform, "Moover" application and their deployments in city state of Singapore. The contribution of the work can be summarised in these categories:

Software engineering Integration of new hardware components, in particular, new types of sensors: sleep-mat sensor, Zwave sensors via Domoticz, UnaBiz LPWAN sensors. New web views for better understanding of the processes: statistical view, combined view, expansion of capabilities of existing views (history navigation). Investigation of issues with data transmission reliability. Implementing, gathering and extracting different metrics (connection logs, usage statistics), development of monitoring services.

Reasoning enhancements A suggestion of "replay" service that deals with delayed events and the need of amendments in the historical record of the reasoning. More precisely, during the standard operation, an event happens, is directly intercepted by the reasoning an an estimation of an activity is produced. However, connection issues can delay some information. In such cases, we need to amend the inference made in the past and update it with the delayed information. The suggestion is to replay the event stream and keep the original historical inference and the most recent inference.

Reasoning additions A contribution was made in creation of an ontological framework for recommendation of a mobility solution from multiple sources. This contribution is part of the work on Moover application. As the backend, UbiSmart, merges several data sources into a simply looking indication for every of 6 selected mobility solutions: walk, bicycle, motorcycle, bus, mass rapid transport, car/taxi. The system uses rules to implement evaluation methods adapted to 6 dimensions: current progress (decimal number), weather (5 categories), air quality (4 categories), extreme temperature (binary) asthma (binary), disability (binary) A part of this contribution is a visualisation of all possible resulting outputs.

Lessons learnt from the deployment This thesis has directly contributed to several research and development projects. All the aforementioned technical work has resulted in a real-life application of the technologies. The real-life applications consist of defining use-cases or personas and validating all necessary steps to perform hardware and software technologies installations. Those steps are first to obtain ethical approvals from the university and local Institutional Review Boards (IRB). They allow researchers to perform local briefing sessions involving possible participants, recruiting the participants into the study, organizing site visits and perform hardware deployments. Once this initial setup is performed, the true value for the deployments is the data collection and subsequent relevant use of data. The data is at core of this thesis. The produced data is a representation of the user's daily activities, physical activity performances, real-time indicators, or even sleep quality data. The desired usage of this data is in enhancing one's quality of life by providing tools, information, analytics or computational services to impact the daily life.

Organisation of Manuscript

The organisation of this thesis is as follows. In the Introduction, the general context of the research and geographical particularities of Singapore, the deployment site for this thesis' output are presented. The topic of smart environments and its components is reviewed in the Chapter 2: State of the Art. Chapter 3 describes the overall design of the UbiSmart platform; including the original and enhancements' design choices, its software components, and their interactions. This is followed by Chapter 4, which explains the further development process. It illustrates the later enhancements and new modifications that were added during the research work for this thesis. In Chapter 5, I examine the usage of the platform in real conditions and the efforts required to prepare a deployment of the system. Next, Chapter 6 presents a particular case of the Moover application, which is a special use case of the platform for mobility recommendation. It describes specifically the reasoning used and the development of a software for Android smartphones as a new interface. The application combines weather forecast, air quality information, current exercise progress and goals. The results are then discussed in Chapter 7, along with the validations of different components of the proposed and deployed systems.

Chapter 8 concludes the thesis and provides openings for further developments and improvements.

State of the Art

Introduction

Many technological solutions tend to be labelled as "smart" or "intelligent". Technically, it applies to software systems exhibiting an intent of intuitive, adjusted or convenient behaviour. Although there are non-physical objects (e.g. "smart contract"), this denomination is commonly attributed to physical objects that embed such a software. Examples include whiteboards, refrigerators, cars, watches, speakers, light bulbs. Often, an ability to be controlled remotely makes the object potentially smart by delegation. From a macroscopic point of view, a system incorporating a smart object has the potential of being attributed the same label. In that sense, we talk about smart homes, networks, and cities. In this case, the interconnection of the "smart" parts in a meaningful system providing a service to people is a key aspect of their intelligence. This chapter explores smart things in our physical environment, technical solutions for making our environment smart, and approaches for the rule-based reasoning.

In the following section, I will review the solutions for AAL and the user centred approach. Despite well known design principles and increasing affordability of the solutions, real life deployments are less common than expected in scientific publications. It is where this thesis aims to contribute by the descriptions of our deployments. Further in this chapter, I present research projects that explain their deployment in real conditions, out of controlled environments. A look into semantics within activity monitoring follows. The acceptability of these monitoring systems is then invoked. The overview of the smart environments is completed by a review of available technologies and components.

Next, section 2.3 of this chapter has a closer look into the reasoning and context understanding outdoor and indoor environments. General context and approaches that have driven this research are mentioned. They are followed by the research related to a possibility of a semantic replay and currently available implementations of a similar concept in the literature.

This thesis builds on The State of the Art and concepts that are given in section 2.4: from general notions in semantic web to distinct types of rules that form our system.

The last section concludes the State of the Art and provides some pointers towards possible evolutions and future contributions.

IoT for Ambient Assisted Living and Mobility Applications

AAL is a part of ambient intelligence research as a specific field of application. The AAL could be defined as an electronic system that is supporting a person in their well-being. The ambient attribute of the system emphasises its integration within the environment and is often expressed as unobtrusive, pervasive, invisible, seamless, or distraction-free. Within the well-being orientation, the assistance covers tasks that became difficult for the user because of a changing health condition (e.g. navigation outdoors for people diagnosed with dementia), or novel elements that have a potential to increase their well-being (e.g. electronic socialising, monitoring and alert systems).

The need for the assisted living can be postponed by lifestyle enhancements. The sooner we adopt good habits for our lifestyle, the later we need an external assistance. In that sense, it is possible to talk about the "future ageing", people of all ages. A prominent issue is the lack of regular physical activity which is a major contributor to chronic diseases [Booth et al. 2012]. One option of avoiding the inactivity and having low barriers is the active mobility, in particular the most common one -the walk. A growing general interest in healthier lifestyle is marked by a development of physical trackers and smartphone applications for fitness and health monitoring. They effectively log and quantify users' lives. By the natural human competitiveness, they push users to achieve better results. The latter is part of gamification strategies that are popular to keep the interest in the product.

Well-being is what connects these two neighbouring domains and also the focal point of this thesis.

Ambient Assisted Living Platforms

A systematic literature review [START_REF] Calvaresi | [END_REF] investigates how the existing platforms address the emerging needs. The main findings indicate that the most of the papers were published after 2007 and mostly written in Europe (fig. 10), in particular in Germany. A contributing factor is the Ambient Assisted Living Joint Programme initiated by the European Union. The solutions generally focus on the patient and the physician, neglecting other stakeholders (for example visitors to the participants [Karkaletsis et al. 2018]). The most commonly addressed topic is patients monitoring and activity recognition. The platforms often feature ad-hoc architectures. They note a lack of evaluation of the solutions' actual usability and how well they satisfy the emerging needs. The aim that is emphasised is a establishment of a rigorous evaluation and validation of existing and novel AAL solutions, and a decrease in technological commitments in favour of needs analysis. "For example, the evidence raised in this review suggests as promising future direction the empowerment of the interaction among all the AAL actors throughout a single solution, that, nowadays is still missing." Following this view, a creation of an extensible platform with very simple aims, and test it in real conditions, seems to be the step in the right direction.

Figure 10: AAL papers per region [START_REF] Calvaresi | [END_REF] Another perspective on AAL and mobility-oriented services is to view it as a part of "quantified self" of "life-logging" research. The authors of [Offermann- van Heek et al. 2019] based on questionnaires (N=1107, participants from Germany), define practical guidelines for platform development. To name a few, ethical aspects are addressed, represented by the manipulation with personal data. They confirm that "older participants tend to accept life-logging technologies and acknowledge potential benefits more than younger people".

In 2010, a very extensive publication on Ambient Intelligence (AmI) and smart environments, [START_REF][END_REF], mentions several projects that became references in current research: CASAS still active [Cook et al. 2013], CAALYX evolving into eCAALYX [Boulos et al. 2011], PERSONA (Perceptive Spaces prOmoting iNdependent Aging) [Fides-Valero et al. 2008] became an input project for latter UniversAAL consolidated platform [Stengler et al. 2015].

As a part of "RADIO" project, [Karkaletsis et al. 2018] focuses on helping elderly people with a robot system. It belongs to projects that already underwent practical testing -in a hospital in Granollers, Spain. The installation could be performed within one working day in most cases. The system detects emerging functional impairments. RADIO project developed ad-hoc Activity of Daily Living (ADL) classifiers based on a rule-based reasoning system (RBR). Their report mentions rules under the form of IF (TV _ energy _ consumption is ON) and (Pressure _ sensor _ chair is ON)THEN Start _ calculation _ watchingTV _ time. No details on their implementation were published.

Under the same RADIO project, an audio analysis for bathroom activity monitoring offering 70 % classification performance [START_REF] Siantikos | [END_REF]]. The considered activities were: Silence -no sound, Flushing water, Shower, Tap water, Other activities.

User Centred Approach

Calls for user-centred approach for design of ambient intelligence were present since the beginning, for example, in [START_REF][END_REF]. Participatory development paradigm can be used to achieve multimodality, accessibility, adaptability, and usability. Furthermore, there is more to the user's involvement than their inclusion in the feedback loop during the development and fast prototyping. [START_REF] O'grady | [END_REF]] discusses an evolutionary development of AAL systems. [Sun et al. 2014] advocate the treatment of users as peers who can not only be on the receiving end of the help but also provide it. The paper describes a computer simulation of matching older people's request for a shared walk and planning. However, their proposition lacks a real implementation and experimental deployment.

The need of evaluation of these systems is expressed in [START_REF] Salvi | [END_REF]] that provides a framework for a platform evaluation. Although the scientific aspects are very important, rarely assessed is the business potential of AAL platforms. For broader domain of AmI, the evaluation method proposed in [Pavlovic et al. 2020] evaluates user experience and business value.

For the evalution long-term real life deployments are needed.

Lack of Deployments

Many laboratories build specific spaces to demonstrate their research in smart home and assistance technologies. Living laboratory allows an illustration of real conditions and can serve for practical testing. Deployments in real conditions are rare and mostly fit within controlled environments (hospitals, nursing homes). The major contributors to AAL research are focused on developing solutions tailored for living laboratories (e.g. the CASAS project).

While a decade ago, the major contributors to AAL research were focused on developing solutions tailored for living laboratories-e.g. the CASAS project [START_REF] Rashidi | [END_REF], the Gator Tech Smart House [START_REF] Helal | [END_REF], the iDorm [Doctor et al. 2005], and the Georgia Tech Aware Home [Abowd & Mynatt 2005]. However, many aspects of a smart assistive home are yet to be explored and the choices made by researchers when developing in laboratories may not remain the same if they had developed on-field [Aloulou et al. 2013].

The lack of real-life deployments was the motivation for [START_REF] Tunca | Multimodal Wireless Sensor Network-Based Ambient Assisted Living in Real Homes with Multiple Residents[END_REF]. Authors deployed their system comprising of 20 sensors, including force sensitive resistors, photocells, digital distance sensors, sonar distance sensors, contact sensors, temperature sensors, pressure mats and infrared receivers. They were deployed in two homes during 30 days. This system differs from classical ones by focusing on multi-user setting with two inhabitants without using wearable sensors (e.g. [START_REF] Wang | [END_REF]). The paper exposes another issue of prototyped platforms -their scalability is usually not a part of their original design. Despite the low-cost profile of used sensors, their large number might hinder the system's affordability and therefore its commercialisation.

A rare example of an AAL system that was deployed for 3 months in real conditions is "SmartSenior@home" [START_REF] Gövercin | [END_REF]]. The prospective cohort study was conducted in Potsdam, Germany, with n = 35 adults 55 to 88 years old in their apartments. It offered over 30 AAL services developed in 3-year collaboration with 28 industrial partners. The backend was supported by 25 data processing units in 12 locations. Participant's home was equipped on average with 36 devices connected to the backend via a broadband Internet connection. The system was operated via a TV screen user interface. The "portal offers smart home, video communication, health monitoring (based on data of a scale, a blood pressure meter, and partially an ECG), and assistance services. Detection of potential precarious situations, a drinking reminder, and an interactive training system for fall prevention and stroke rehabilitation complete the offered services". On average, the user interface was used every other day.

Their results indicate moderate-to-high user acceptance of their system, providing general assistance, including a consultation with a health professional, blood pressure monitoring. A promotion of social interaction and reminders were less popular.

Diversity of Technologies and Aims

A particularly noteworthy system deployed in real conditions, [Kim et al. 2017] performs a depression diagnosis from 90-day long deployment of sensors in elderly people's homes (N=20, aged 69 to 90 years). The used sensors are of two types: contact sensor and motion sensors. This study could be applied on the datasets collected by our deployments as they use a subset of sensors used in ours. The designed solution might be used for an early detection of the illness. The study admits that the sample had limitations as only one participant was diagnosed with severe depression. Therefore, a larger study is needed to validate more precise detections.

The study [Olsson et al. 2018] points out the broad impact on patients' and their families' lives. Installing sensor technology with individually pre-recorded voice reminders as memory support in the home. "These effects were both positive and negative. The sensor technology not only supported activities but also influenced the patients by changing behavior, providing a sense of security, independence and increased self-confidence. For the partners, the sensor technology eased daily life, but also gave increased responsibility for maintenance. Technical problems led to frustration and stress for the patients."

Context-aware services like reminders or ADL assistance, for example via a multimodal interactive system be used to tackle the Quality of Life (QoL) aspects of people's lives [START_REF] Mokhtari | [END_REF]].

An example of non-invasive monitoring is the monitoring of electrical appliances presented in [Franco et al. 2008], Wi-Fi [Al-qaness 2019, Li et al. 2018, Wang et al. 2015]. For early detection of health issues, [Hagler et al. 2010, Luo et al. 2016] use gait measurements.

Work on detection of falls in a house uses a variety of solutions, including Wireless-Fidelity wireless networking (Wi-Fi) [START_REF] Wang | [END_REF], depth maps on video, infrared arrays or floor vibration sensing setups [Rougier et al. 2011, Sixsmith & Johnson 2004]. Simple solution is proposed in [START_REF] Floeck | [END_REF] alerts are sent to a family member in case the movement detected in the home is abnormally low. Ste-lios et al. perform indoor location of the residents to provide medical notifications in the environment [Stelios et al. 2008].

Activity Monitoring with Semantics

As already mentioned in [START_REF] Calvaresi | [END_REF], monitoring of elderly people's activity is one of the main research topics in AAL.

Wearables and sensors were used in the case study of an AAL system for Alzheimer patients [Cavallo et al. 2014] deploy localisation services and cognitive stimulation. Validation was performed with 14 participants over an undisclosed period of time. The provided services include Exit/entrance monitoring, Multimedia cognitive stimulation, Support in taking drugs, Automatic lighting at night, Recognition of rising from bed, Recognition of fall and alerting, Support in outdoor localization, Control of gas and water electron valve, Control of access to cabinets and lockers, Support in using phone, Support if night agitation, and Multimedia communication.

Another semantic knowledge approach, similar to ours, is implemented in [Syafiq et al. 2018]. A similarity to our system is in the modelling of the system by an ontology. It differs for the activity recognition as they use clustering and machine learning. Details about the reasoning use and about experimentation are not extensive and some more are provided in [Abdull Sukor et al. 2019]. A real-life deployment is absent. They combine the machine learning (preprocessing the sensor data) and the rule-based reasoning. A for a further development might be the need of large quantity of the sensor data. It is not clear how the clustering algorithms will adapt to different users. The test-case was carried out during 28 days by one 26-years-old male participant. [Chen et al. 2014] proposes an iterative 3-phase hybrid approach to activity modelling: knowledge-driven activity modelling, model-based activity recognition, datadriven activity learning. The data flow makes this system evolve in the following way. The model powers the recognition, which in turn provides data to learning component. The learning component then influences the model and the cycle is completed. Their approach was tested in a controlled environment.

A particular part of context-aware system development is the rule-based systems embedded directly in mobile devices. The paper [Nalepa & Bobek 2014] proposes and [Bobek et al. 2018] updates a rule-based approach for mobile context-based applications. The main advantage, compared to cloud-based systems, is the absence of transmission of the data over networks to other computer system. It may increase the perception of privacy and security as it could be exposed to an attack during the transmission or on the remote server. The system is based on XTT2 rules which can be (partially) translated to OWL format, using "HaThoR" tool. The family of manipulation tools includes an online web editor HWEd and an advanced visual editor HQEd. Their most recent applications include emotional context for games and intelligent assistants [Nalepa et al. 2019].

In [START_REF] Wrede | [END_REF], a spatio-temporal operators are introduced and allow for more expressive strategies for activity detection.

Acceptance of the Systems

In 2010, the outlook of AAL by caregivers and health professionals was positive and promising [Siegel et al. 2014]. In 2018, the results were more mitigated in [Heek et al. 2018], studying acceptance of AAL systems by professional caregivers. Respondents answered scenario-based online questionnaire (N=287). The acceptance of studied AAL technologies was evaluated on the scale of 1.0 (lowest = rejection) to 6.0 (highest = agreement) with 3.5 being neutral. Overall acceptance was rather neutral (M = 3.6; SD = 1.3). Comparatively, a system consisting only of room sensors (M = 4.0; SD = 1.5) received the highest evaluation, while a system consisting of all mentioned technologies except of a camera was assessed worst (M = 2.9; SD = 1.4). Another web-based survey [Offermann-van Heek & Ziefle 2018] (N=170) indicated that caregivers of disabled people were more critical towards AAL system than geriatric or medical.

In [Shahrestani 2017], the authors emphasise that many researchers believe that focusing on technical aspects and functionality at the expense of ignoring the human and social dimensions of assistive technologies may have hindered the development of proper assistive devices and services. Many devices stay prototypes. Concerning the quality of life, they highlight eight domains: emotional well-being, interpersonal relationships, financial and material security, personal development, physical heath, self-determination, social inclusion, and rights.

The importance of interoperability between AAL platforms has been promoted for years however no satisfying standards were broadly adopted. [Ben [START_REF] Hmida | Enabling an internet of things framework for ambient assisted living[END_REF] proposes a generic framework for IoT reasoning, [El Murabet et al. 2019] promotes a context-aware reference architecture for AAL. The authors provide a model of concepts necessary for an AAL system. What seems missing is a machinereadable version of these specifications that are presented in figures, for example as an ontology.

In the following subsections I will cover currently available platforms and hardware components suitable for a mobility-oriented ambient assisted living.

Smart Homes and Smart Environments

Smart homes and smart environments can increase the degree of convenience and practicality for home-dwellers. A common issue that one may face is the sudden realisation that they might have forgotten to switch the lights or other electrical appliances off before leaving the home. During winter, it is now possible to switch the heating on and off via a timer so that the energy is not wasted. The possibility of being able to control the heating remotely, and turn it on in advance, is also very appealing, as one can enjoy the comfort of getting into a warm dwelling immediately. If a window opens while the inhabitant is not at home, a sound alarm could be triggered. Another design for greater convenience is the tracking of energy consumption per appliance, to enable home-dwellers to view and monitor their usage patterns. This would allow them to get a clearer idea of how to consume energy more efficiently and lower the electricity bill. These simple use cases illustrate some of motivations behind the building and development of smart homes: practical use, remote command, automation, and security features.

Since the early 2000s, there have been a surge in home automation solutions to meet increasingly popular demands, and gaining a market share quickly. At the same time, connected devices have been identified as a serious security threat [Schiefer 2015]. The embedded systems were found extremely vulnerable to simple attacks and having a very high potential for exploitation in automated robot networks (botnets) [Angrishi 2017].

A wide range of devices is now on the market, ranging from hardware single-purpose components for electronics enthusiasts, through components using standardised communication technologies, to complete branded sets of sensors. Some of the mass market solutions include smart assistants from global brands like Google and Amazon, as well as active and passive components such as smart blinds, doors or plugs. It is also common for hardware enthusiasts and hobbyists to share their home-made solutions on online platforms and forums. The spectrum can thus spread from cheap but requiring some knowledge and manual skill to make them work, to expensive but ready-to-deploy without any technical knowledge. Nevertheless, it remains possible and also important to attain a balance between price and time spent on interoperability issues, which fits the intended use case.

The scope of the research concerns computer science and therefore, this thesis will focus on elements using standard protocols, omitting low level hardware solutions and home-made ad-hoc sensors.

Several IoT oriented standards compete, with the most popular in late 2010s being Zigbee and Z-Wave. They are competing with wireless communication standards with a broader us: Wi-Fi and Bluetooth. These direct transmission protocols also have more recent competitors -carrier-operated networks such the recently announced 5G, as well as low power and low bandwidth networks like SigFox. Both of these require a carrier coverage provided by a third party stations.

Many tools have been developed to take advantage of the well known protocols; the devices can be connected through multi-purpose platforms, like OpenHAB, Domoticz, Jeedom and the most recent Home Assistant. An overview of a selection of these platforms is presented in table 1 A multitude of open source platforms also emerged. They differ in backend technologies and their purposes range from home automation, home or inhabitants' monitoring, to media centre with special features oriented to playing video games.

The arrival of cheap single board computers (Raspberry Pi, its clones like Banana Pi, Orange Pi, and competitors Asus TinkerBoard), sparkled multiple home-made applications. These Do-It-Yourself solutions for hobbyists or ordinary home-dwellers include simple controllers for watering the plants, and even smart mirrors with touch screen features that allow one to read the latest news when getting ready.

The various creative solutions and innovative designs could be further extended and enhanced to cater to the needs and well-being of other groups, such as elderly people, children, or those with special needs. Especially for these groups with special needs, it is necessary to ensure that the design solutions attain a good balance between privacy and functionality.

In the context of elderly care, [START_REF] Uddin | [END_REF]] provides a survey of applications using sensors for activity recognition and fall detection. The survey includes systems based on floor sensors, radar sensors, sound sensors, pressure sensors, video sensors and passive infrared sensors. As the survey points out, the most of papers used the video sensors for their application (detection of activities of daily living, resident location or fall detection). Although video recordings are convenient for offline analysis, there is an important privacy issue. Despite their high accuracy (e.g. [De Miguel et al. 2017] reports 96 % fall detection ratio), they also represent an intrusion into the resident's privacy. Even with fully secured device, the presence of a video camera alone makes people feel uncomfortable.

Wearable Sensors

A very specific group of IoT devices is designed to be worn. Usually, they are powered with rechargeable batteries and worn either as a piece of clothing (T-shirt), an accessory (bracelet, necklace), or as an everyday object or aid (walking stick, earpiece).

These objects are constrained in size, and are required to be energetically selfsufficient for at least an entire day to be practical. A selection of these devices and their potential in the activity recognition are presented. Compared to a smartphone, a smart watch is more limited in terms of power con-sumption. For this reason, the watch needs to be paired with a smartphone. According to developer's guides for Android and iOS platforms, all resource intensive computations should be performed on the smartphone. The Operating System (OS) for these devices is often closely linked to the smartphone platform. Apple Watch operates on "watchOS" and it operates only with iOS device from the same manufacturer, Apple. "Wear OS", formerly known as "Android Wear" is an Android operating system designed for smart watches and other wearables. In our system architecture the use of these devices was initially mainly for notifications about activities and potential dangerous situations. As the development progressed, the data from the devices (step count, sleep durations) were included into datasets and reasoning processes.

43 000 students from primary schools, secondary schools and junior colleges over the period of September to November 2015. The initiative helped to determine the travel patterns of the young inhabitants, the time they typically spend outdoors, on top of noise levels in different regions. It also served as science experiments for the young learners as the sensor outputs were made available for the students to use.

Passive sensing By their nature, beacons do not collect any data. Rather, they emit a signal that can be intercepted by other devices. In particular, Bluetooth beacons or Bluetooth tags (fig. 13) became popular for IoT applications. For example, Singapore National Gallery deployed them inside their premises to provide a location and orientation service. With the gallery's mobile application. the visitor's smartphone detects the beacons and performs the triangulation. In this way, they provide rich media content that is related to the piece of art that the visitor is currently viewing. As this necessitates a large amount of data consumption, the gallery also provides a Wi-Fi connection access along with the application itself.

At the same time, one beacon-related issue is the cost of battery exchanges. The beacon manufacturer Estimote mentions the possibility of using "tags", which are smaller and less durable beacons, to locate objects of everyday use, such as handbags or bicycles. In 2015, tags from Connecthings were deployed across the the French city of Montpellier, allowing commuters to access and interact with real-time information on public transportation through a smartphone. Clothing items and everyday objects Electronic components as part of the common items is an interesting option how to reduce the number of devices that a person needs to carry with them. As an example, in fig. 14, socks, T-shirts or umbrellas and walking stick can be enabled to gather the information related to physical activity and either transmit it directly to a smartphone or later hand the information over for analysis. These devices contribute to an unobtrusive monitoring. The user interacts with the device through a large touch-screen covering one side of the device. Current use of a smartphone is ubiquitous and has become an essential accessory for communication, news and entertainment. Any current smartphone contains numerous sensors (accelerometer, Global Positioning System (GPS), magnetic field). With the increasing processing power, it can be used not only for collection of the information but also for its processing.

Implanted sensors These have mostly remained a futuristic possibility that has not yet earned a large momentum. For instance, passive microchips have been deployed in Sweden, where they replace access cards for office workers. They use Near-Field Communication (NFC) technology, and there is "a small, but indeed fast-growing, fraction which has chosen to try it out."8 .

Reasoning Indoors and Outdoors

Context understanding is crucial for intelligent systems that provide assistance. In an event-based perception of the environment, the context could be captured by two elements. One of them is a model of the environment and relationships between its elements can be called an ontology. The other one is the interpretation of the events that happen during the runtime, i.e. detection mechanisms or rules.

Representing Contextual Information

Context-aware services were highlighted as the research trends in industry [Xu et al. 2014], defined by the European Union as one of important research area.

The difference between the sensor data and the contextual data is explained in [START_REF] Hong | [END_REF]. The distinction is important because the sensor data is not ambiguous and has attributes: granularity, precision, accuracy. These characteristics influence the interpretation of the data, hence the Quality of Information (QoI) and its model is a very important factor in the design of a system. [Henricksen et al. 2002] brings a conceptual proposition of a semantic labelling of the QoI. Despite non-disclosure of the estimation mechanism details, it is worth highlighting the peculiarities of contextual information:

1. imperfection (incorrect, inconsistent, incomplete or expired information)

2. temporal characteristics (information being either static or dynamic), 3. multiple facets (support multiple representations of a same context at various level of abstraction and capturing the relations between these several representations).

The QoI brings us to modelling of the information. The model, a computational representation of a system, is a key component for an intelligent system. It is the main support of a computational understanding of low-level events and their connection to the context (higher-level events). Modelling technologies have often a form of a schema (e.g. Unified Modeling Language (UML) for implementation of classes in object-oriented programming). A more versatile technology has been introduced in early 2000's -Semantic Web. The concept started with the aim of making comput-ers able to read the web. Description Logic as a provides a theoretical framework for a formal analysis of the technology. In particular, ontological representations in open formats are of interest. World Wide Web Consortium (W3C) supervises the formal definition an evolution of recommendations and related standards.

In Semantic Web, ontological representations can be interchanged and combined. This interoperability is ensured by an Uniform Resource Identifier (URI) that is assigned by each ontology creator who is responsible for using unique identifiers.

A URI has a form of an Uniform Resource Locator (URL) and, generally, can be accessed in a web browser to provide the definition of the resource. The use of the ontologies spread to other applications.

A use of a semantic web modelling with Extensible Markup Language (XML) is presented in [Nugent et al. 2007]. The authors describe its use to formalise various aspects of AAL and context reasoning. Their XML-based solution, HomeML is designed to represent the information transiting in AAL systems. A more recent system is described in [Chen et al. 2014], where standard ontology design tools (e.g. OWL2 format) are used and they model user with a profile and use machine learning to discover new activities.

Executable model

An ontology ensures the vocabulary, the data fills the knowledge base, rules manipulate the knowledge base and extract new information. With Turtle, N3 and likewise, it is possible to specify all three components within the same language. It can be seen as an executable model. The execution is performed by a reasoner, or inference engine.

The contextual information provided by sensors is limited by low granularity. By design and choice, sensors a very specific and limited information in low quantities.

The broadly adopted machine learning techniques and statistical methods (Support Vector Machines (SVM), Hidden Markov Models (HMM)) would not have captured the trends [START_REF] Mokhtari | New trends to support independence in persons with mild dementia-a mini-review[END_REF]. Rule-based systems are usable for low granularity data. However, complex rules are more difficult to be formulated. Following our no cold-start constraint, rule-based methods satisfy our research requirements.

Common sense and expert knowledge are generally necessary to create a model of user activities and environmental factors. In order to make the data understandable by a machine, knowledge engineering is deployed. Even if it is possible to implement reasoning in imperative programming languages (Java, C), descriptive problem solving is more adapted (e.g. Prolog). Declarative approach offers a more efficient separation between the model and the model it manipulates [Luther et al. 2009].

Declarative methods could be tracked to Domain Specific Languages (DSL) that feature non-standard modelling and rules languages [START_REF] Jiaqi | [END_REF], Artikis et al. 2010].

Currently, Semantic Web technologies offer standardized languages and syntaxes.

The Description Logic (DL) covers the theory and expressivity [START_REF][END_REF][START_REF] Mokhtari | New trends to support independence in persons with mild dementia-a mini-review[END_REF]. The main advantage of these semantic technologies is the reusability and adaptability of the resulting system. In order to implement a solution in a massive deployment, it needs to scale and have these properties. A complete description of the technological alternatives is provided in [START_REF] Mokhtari | New trends to support independence in persons with mild dementia-a mini-review[END_REF]

Semantic Replay

Very little research has been done in replaying of the events. When dealing with historical sensor readings for post-processing, the premise is to consider the data missing and ignore it or to interpolate it [Halatchev & Gruenwald 2005]. For sensor data that is being processed in a stream, the common attitude is to drop the events that arrive late. In cases of relatively short delay (network delay), buffering and reordering before the reception can solve the problem [Mutschler & Philippsen 2013]. However, when the decision about the activity already has been taken, we need to backtrack on the decisions impacted by the delayed event, repair it.

"Reasoning replay" is a term that emerged from our platform implementation: it is the mechanism of resubmitting the knowledge to the reasoner in order to include facts omitted because they were unavailable at the moment when the decision making process was performed. Some systems accomplish a similar task without using this term -either because of its triviality (in trace based systems) where the reasoning replay is the key component of the design and the main functionality; or because of little or no added value in real-time systems with critical decision process and dilemmas (e.g. in driver-less cars). Our type of application of activity tracking fits in-between: decision repair is technically possible, and can greatly benefit the user monitoring the activity in real time. In the domain of activity tracking and ontology-based systems, we can find several technological solutions neighbouring our domain.

Trace-driven systems provide an interesting insight into data processing. One of the engines allowing to build such systems is kTBS, "a kernel for Trace-Based Systems" [Champin et al. 2011]. It provides a formalisation of a model of a trace, and Representational State Transfer (REST) Application Programming Interface (API) for storing and querying the data. The data being treated as a trace introduces several interesting concepts. A trace is viewed as a container for observed elements. Instead of a time-stamp, it uses a broader concept of an origin that allows reasoning over co-occurrence of elements without time-stamp. Another interesting feature is the differentiation between stored trace and computed trace. This trace-centred approach seems to be compatible with our approaches and we need to investigate the possibility of merging both. [Zarka 2011] dedicates a chapter to the replay strategies for stored modelled traces.

Amongst applications built with kTBS, we can mention semantic wiki interaction tracking via a browser plugin described in [START_REF][END_REF]]. Activity tracking is based directly on computer-collected trace, and they examine the on-line behaviour of the users.

Similar concepts to ours, and their recent evolution are presented in [Hu et al. 2016].

The authors offer a full plug & play solution for a "Smart home in a box", although they do not mention any semantic replay, error correction, or processing of delayed events. Another daily activity tracking application is described in [Cook 2010]. The traces are post-processed and it does not seem to have any real-time monitoring use case.

Using a different perspective, field of stream reasoning provides a solid formalisation of reasoning over a possibly massive knowledge stream (e.g. sensor events). The last decade displayed intensive efforts summarised in [START_REF] Dell'aglio | [END_REF], notably in querying, benchmarking, and incremental reasoning. Similar to our problem, in [Beck et al. 2015], the authors tackled the issue of updating the knowledge in a non-monotonic reasoner.

Semantic Model for the Activity Inference

This section describes the model that was used within the platform and in particular implementations done by Thibaut Tiberghien who set the platform this thesis contributed to.

The terms Terminological Box (TBox) and Assertional Box (ABox) are used to describe two different types of statements in ontologies. TBox statements provide a conceptual description of a system or domain in terms of classes and properties; hence defining a vocabulary. ABox statements are TBox-compliant statements about individuals constituting this system or domain. TBox statements are sometimes associated with object-oriented classes and ABox statements associated with instances of these classes. Together, these statements make up a knowledge base. Until the end of this paragraph, we will use the convention that classes are referred to by a word with a first letter in upper case (e.g. Class) and its resources by the class name in lower case (e.g. class or classes). Relations will be represented by a camel cased word surrounded by brackets (e.g. (propertyOf)). The objects can optionally be (locatedIn) a specific house or room. The vocabulary also allows for the description of the sensors deployed in the house. The sensors, of different sensortypes, should either be (attachedTo) an object or (deployedIn) an environment like a room. All sensorstates are declared and the active states providing an informa-tion of type location or object use are characterised with datatype properties using boolean literals (indicateLocation) and (indicateUse). Additionally, a class is provided to describe activities that the residents could be doing (believedToDo); where potentially dangerous activities are defined into the sub-class Deviance. Datatype properties, linking resources with literals, are also defined to keep track of timestamps such as the latest activation of a sensor (lastUpdate), the latest use of an object (lastUsed), the time when a resident was first detected in a room (inRoomSince) or believed to perform an activity (doesActivitySince). These properties are also used to store numerical variables, such as sensor values (hasValue) or the amount of motion measured in rooms (motionMeasured), as well as parameters, like the risk level of a deviance (riskLevel). We finally use datatype properties to store inference results like a boolean to flag the detection of multiple people (isAlone), or a decimal confidence scores given to each activity in the reasoning process (getConfidenceScore).

Assertional Box

As explained in the previous section, the ABox of the ontology contains all statements describing the actual environment of deployment in a TBoxterms, i.e. using the vocabulary described above. This representation could be considered as a projection of the deployment's reality into the semantic model provided by the TBox. It includes the house, the sensing system, the residents and the different activities of interest. A minimal functional extract of an ABox in Source 1.

Actual ontologies naturally contain more rooms, sensors and activities. The @prefix at the top of the document defines the namespaces used in the document, each namespace will be considered as known for the subsequent source codes where only new namespaces will be given. N3 has some syntactic sugar that allows abbreviations and factorizations; for instance the predicate rdf:type, which is used to state that a resource is an instance of a class, can be abbreviated as the letter "a" (as in "is a"). Moreover, if several statements are written for the same subject, then predicate-object pairs can be separated by semicolons (";").

Source 1 -N3 Description of a Home @prefix qol: <model#>.

@prefix hom: <home#>.

## Home (with example rooms)

hom:france a qol:Environment.

## Activities (examples)

hom:getUp a qol:Activity.

hom:goToilet a qol:Activity.

hom:fall a qol:Deviance.

Rule-Based Activity Inference

The aim is to provide a recognition of activities in real-time and with no coldstart, i.e. without requiring any learning of the lifestyle of the residents. In order to achieve it, Tiberghien had implemented an explicit rule-based inference of the activities performed by the residents with no prior assumption made about their lifestyle. The principle was reused for further rule definitions during this thesis. This implies that the conditions must be chosen carefully to capture the activity for the most of cases, especially for unusual cases that might indicate the elderly person's issues. For example, we cannot assume that the sleep occurs only at night and is continuous. A person could be sleeping late at night and for a short period of time, while compensating by naps during the day. The time at which they take their meals might be unpredictable as well. A consultation with medical doctors clarified that erratic patterns do not represent an issue. A stronger indicator of potential clinical condition is a change in habits over time.

It is clear that the rules must be, on one hand, true to sensor events and provide logical inference, on the other hand, they should make some minimal assumptions based on common sense. If the two approaches collide, the set of rules has to provide a way of resolution of this conflict. Taking into account these observations, the activity inference features three complementary types of rules: rational rules, intuitive rules, and arbitration rules.

Similarly and applied to the AmI field, rules use to infer contextual knowledge should ideally be rational, i.e. abstract rules that translate some irrevocable knowledge or common sense and can be applied with no doubt about the existence of a contradiction. However, due to limitations emerging from both the situational data available and our modelling faculties, such rules cannot always be written. This leads to the intuitive rules that translate products of experience and intuition, which however may happen to yield to contradictions. These types of rules are described in details below.

Rational Rules

These rules perform the fusion and augmentation of contextual data received from sensors into higher level contextual information such as residents' location or their use of objects. We refer here to rationalism because these rules basically are translated from known scientific models or common sense. For example, in Source 2, a rule is tracking the location of residents in their house. This rule is formalized in DL below for reference and comparison with its N3 syntax given in Source 2.

∀ sensor se; state st; room r, r2; house h; resident u; time t; (se hasCurrentState st) ∧ (se hasLastUpdate true)

∧ (st indicateLocation true) ∧ (se deployedIn r) ∧ (r partOf h) ∧ (u liveIn h) ∧ (u detectedIn r2) ∧ (r2 = r) ∧ (se lastUpdate t) ⇒ (u detectedIn r) ∧ (u cameFrom r2) ∧ (u inRoomSince t)
In the rule, lastUpdate gives the timestamp of the last event for each sensor, while hasLastUpdate is a boolean flagging the sensor which sent the last event that started the reasoning cycle.

Source 2 -N3 Rules of Type I (Rationalism) @prefix log: <http://www.w3.org/2000/10/swap/log#>. @prefix math: <http://www.w3.org/2000/10/swap/math#>.

## track resident location [live + persistent]

{?se qol:hasCurrentState ?st. ?se qol:hasLastUpdate true. ?st qol:indicateLocation true.

?se qol:deployedIn ?r. ?r qol:partOf ?h. ?u qol:liveIn ?h. ?u qol:detectedIn ?r2. ?r log:notEqualTo ?r2. ?se qol:lastUpdate ?t} => {?u qol:detectedIn ?r. ?u qol: cameFrom ?r2. ?u qol:inRoomSince ?t}.

Intuitive Rules

These rules reflect some domain knowledge emerging from experts' experience, intuition and insight [Wallace 2007]. Every rule independently attributes points to an activity -which could be seen as a vote. The score given by a rule should increase when either the activity or the rule is more meaningful; for example, the "sleep" activity in Source 3 is considered specific and can be distinguished easily from others so it receives a high score, whereas the "occupied" activity is more like a default activity when movement is detected and nothing more precise can be told about the context of the resident, thus it receives a lower score. Dangerous activities which cannot be missed are also given a high score as can be seen for "fall". Rules can also give a negative score to vote against activities in order to balance positive scores given by other rules. For example, we can see that the second rule for "occupied" and "sleep" decreases the score obtained by the activity when it has been inferred continuously for a long time. This is useful to take into account the maximum duration for which it is safe to accept an activity. Detecting that a resident has been showering for three hours would probably highlight some unidentified issue and decreasing the score of the activity prior to this enables us to detect such a situation. The score is decreased in one step in the example, but some fuzzy scoring is also possible. By convention, scores are set to range from -10 to 10.

Source 3 -N3 Rules of Type II (Empiricism) @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix xsd: <http://www.w3.org/2001/XMLSchema#>. @prefix func: <http://www.w3.org/2007/rif-builtin-function#>. @prefix prof: <profile#>.

## definition of localy useful property

:getScore a rdf:DatatypeProperty; rdfs:comment "Indicates that a rule is in favor of recognizing an activity with a score ."@en; rdfs:comment "the score should be from -10 to 10."@en; rdfs:domain qol:Activity; rdfs:range xsd:int.

## go to the toilet (+ max duration)

{?u qol:detectedIn ?r. ?r a qol:Toilet. ?u qol:inRoomFor ?d. ?d math:lessThan ?u!prof: maxToiletDuration} => {hom:goToilet :getScore 7}.

## occupied (+ max duration)

{?u qol:liveIn ?h. ?h qol:motionMeasured ?m. ?m math:notLessThan ?u!prof: minOccupiedMotion} => {hom:occupied :getScore 2}.

{?u qol:believedToDo hom:occupied. ?u qol:doesActivityFor ?d. ?d math:notLessThan ?u! prof:maxOccupiedDuration} => {hom:occupied :getScore -1}.

## sleep (+ max duration)

{?u qol:detectedIn ?r. ?r a qol:Bedroom. ?u qol:inRoomFor ?d. ?d math:notLessThan ?u! prof:minSleepInitiation. ?r qol:motionMeasured ?m. ?m math:lessThan ?u!prof: Tuning the scores might need a good understanding of the system to distinguish the relative importance of activities to be detected. A special attention is required to handle overlaps in activities. Aspects to be considered are the criticality of the activity, the specificity of the activity, and the specificity of the rule.

Arbitration Rules

The rules of the third type arbitrate -they compute the Rule-Based Confidence Score (RBCS) for every activity. Highest score determines which activity is the most probable one. The RBCS of an activity is computed as a percentage of points attributed to an activity out of all distributed points. It requires to sum scores for each activity as getFinalScore (first rule in Source 4). {?ac :getScore ?x. ?SCOPE e:findall (?sc {?ac :getScore ?sc} ?list). ?list math:sum ?total} => {?ac :getFinalScore ?total}.

{?SCOPE e:findall (?sc {?ac :getScore ?sc} ?list). ?list math:sum ?grandtotal.

?grandtotal math:lessThan 1} => {hom:nothing :getScore 10}.

{?SCOPE e:findall (?sc {?ac :getFinalScore ?sc} ?list). ?list math:sum ?grandtotal.

?grandtotal math:notLessThan 0.1. ?ac0 :getFinalScore ?fs. (?fs ?grandtotal) math: quotient ?cs} => {?ac0 qol:getRBConfidenceScore ?cs}.

## infer most probable activity [persistent only]

{?SCOPE e:findall (?rbc {?ac qol:getRBConfidenceScore ?rbc} ?list). ?list e:max ?maxrbc.

?ac qol:getRBConfidenceScore ?maxrbc. ?u qol:liveIn ?h. hom:clock qol:hasValue ?now} => {?u qol:believedToDo ?ac. ?u qol:doesActivitySince ?now}.

Active Predicates

A special feature of this system is that some predicates have an impact on the Knowledge Base (KB). This can be needed, especially, when updating an information. This provides rules a possibility to perform actions different from adding the information. A graphical representation of a rule fig. 17 helps to elicit the use of updateObject predicate. We could call it an active predicate, as its presence triggers a modification in the KB that is done by an component external to the reasoning engine (javascript).

The reasoning must be flexible enough to take into account the events that come too late. The most common situation is when the 3G router stops working and sensor events keep arriving to the module responsible for delivering them to UbiSmart. The events therefore wait till the connection is restored. Due to limited access to people's homes, this can take several days. The reasoning cycle should take the late events into account and recompute the past activities according to the new information about that time [Kodyš et al. 2017a].

Figure 17: Graph of a rule containing updateObject predicate

Conclusion

In this chapter, I reviewed non-clinical IoT solutions available in our physical environment. The reviewed solutions fall within categories of IoT for AAL, smart homes and smart environments, and wearable sensors. Within these categories, I have reviewed specific type of devices, such as SENSg wearable device that has been used in real-life applications in Singapore, involving hundreds of students from primary and secondary schools, being of Singapore's most inspiring use cases.

Context understanding is the key step for intervention systems. As a part of it, a model of an environment including the relationships between its components is required for an accurate data interpretation. In this work, I have reviewed rulebased methods, pattern-matching techniques and reasoning limitations.

In conclusion, system designers should put the user in the centre of the design and operation processes of the system. An analysis of user's needs combined with current and confirmed approaches to the treatment of chronic illnesses is a cornerstone for the design. They provide constraints and at least partial descriptions, and therefore a model, for the implementation. Thus, all connected sensors and recognition technologies need to be articulated around the user and their environment, providing accurate interpretation of the data, personalized and adapted to each user's particularity and profile.

System Design of a Seamless IoT Framework

Introduction

This chapter introduces the ways of designing conceptual models for our system, specifying design choices as well as their strengths and weaknesses. Also, I will specify how potential extension has been envisioned and how they can be incorporated.

The chosen approach is user centred and knowledge based approach The incorporation of these approaches in the system design encompasses feedback from users during development and testing in a pilot site (for elderly people related research), on top of user feedback from the mobility application deployment.

The design process was continuous and driven by knowledge necessities; regarding the user, their environment, and the interconnection of influences necessary to provide the final service.

Problem Statement

The main purpose of the UbiSmart platform applications is to provide an enhancement of life. Taking into account specific features within the target groups is crucial. Mobility is a key point shared between the two target groups: elderly people and those suffering from a chronic disease (specifically type II diabetes or asthma).

On one hand, the design of a system helping elderly people represents a challenge in terms of the ease of use. The system must be flexible, readily available, easily maintainable, reliable, robust, provide guarantee of being secured, and protect the privacy of its end users. On the other hand, people with chronic diseases are getting diagnosed earlier and therefore, the system should also be interactive and fulfil the expectations of a younger and more active group.

Scientific Challenges

Designing a sustainable platform brings a challenge in software engineering. The scientific part of the challenge lies in rule-generation, which is basically manual according to human intuition. This approach might be useful at the beginning stage, but any computer system that has a real strategy will sooner or later beat the human rule strategy "guess and repair".

As we generate hypothetical rules, it is necessary to validate them. A gradual validation -from simple to more evolved models, and after a confirmation, the rule is executed in practice. The validation can be performed in a test environment where the new rules can be added, using the same input data to compare the outputs. An answer to this problem might be a replay of the reasoning that finds its usage not only in potential rule generation, but mainly in repairing the result of reasoning after missing some parts of the data (because of a modem breakdown).

Another research question is what happens if the person does multiple activities. As the original system supposes, there is only one activity that can be performed by the user at once. However, a user rarely does only one thing and constraint of a single activity potentially reduces the reality. For instance, a person can interact with their smartphone (reading a recipe) while preparing food; read news while walking; play a video-game or write a thesis while being on a transportation. Therefore, the challenge of handling multiple activities at the same time is relevant issue worth addressing.

Monitoring the home environment is practical but as we identify the major factors of well-being like mobility, it is necessary to include outdoor monitoring as well. Furthermore, we can provide a certain guidance involving the information that is readily available via various data providers, including governmental agencies, public services, communal initiatives or private sector. For example, in order to be able to recommend the best mobility for a person, in addition to knowing their profile, we can enhance the recommendation by including the weather forecast, air quality and possibly other factors in the computation. These impact one's decisions about what mobility solution is the best given the current conditions.

Use Cases

Several use cases have been identified and are illustrated on personas presented in this section. The personas are intended to provide a fictive example person representing a specific target group of people that could use the platform. In system design and software engineering, personas allow the developer to sympathise with and therefore, can better answer to the needs of potential users. The concrete description and a scenario or story help to focus on the user. Being the result of teamwork, having a team help to break prejudices an individual developer could have about the users' needs. It is nevertheless necessary to note that personas do not represent all possible nor the real use of the platform. In order to verify how well the application is designed, it is deployed and tested by real users. • Ms Tan has a hectic professional agenda, beginning with early morning board meetings and ending with business dinners in town.

Personas and Scenarios for Mobility Application

A. Use-Case 1 -Preventing Tiredness

• Recently, she started to feel tired and sleepy during the day. She realised that her sleep has been affected by her professional activities and that she has missed her weekly volleyball training too many times.

• Ms Tan usually drives to work and around the city for her meetings. She is concerned about her level of concentration while she is driving. She would like to 52 3.4 Use Cases know more about her health condition and make sure that she is safe while she is on the move.

• She will use a dedicated app linked to the JUVO sleep mat to get information about her sleep quality and tiredness level when she wakes up every morning. The app will recommend to her the best mean of transportation depending on her physical shape. If her tiredness level is too high, the app will suggest that Ms Tan take public transport and guide her through. Alternatively, within the vehicle, the car atmosphere will also adapt to her tiredness and concentration level.

• Ms Tan will thus be motivated to lead a healthier lifestyle in modifying her agenda when possible. While she relieves stress from planning her journey around, she can get back to her volleyball training and find balance again. Keywords: lifestyle coaching, car ambient system, public transport, sleep, tiredness, drowsiness, safety, stress

B. Use-case 2 -The Diabetes Journey

Name: The Yee Family Age: Brian Yee ( 22) and Amina Yee (58) Position: University student and Housewife Goals:

1. Manage smoothly their Diabetes condition 2. Continue visiting grandparents in Malaysia

Stay active and practice physical activities

Brian and Amina in "The Diabetes Journey" scenario:

• Brian is a university student diagnosed from early stage Type II Diabetes. He lives with his parents who are concerned about his condition and want to make sure he does not go into developed or complicated forms of Diabetes. He likes to perform outdoor activities during the week-ends or afternoon when he has no classes. Usually, he plays soccer with his friends or ride bicycles.

• His mother, Amina, has developed Diabetes 20 years ago. She is used to manage her chronic condition through diet, physical exercise and insulin intake when needed.

• The family GP follows both Amina and Brian carefully. He has suggested them to pursue regular physical activity, stay active and continue travelling to Amina's parents' house in neighbouring Malaysia. He is keen on using technology to follow up with them.

• Recently, Amina felt a bit afraid of driving to Malaysia and spending many days in her parents' house where she has not the same services and infrastructure as in Singapore. As a matter of fact, the Yee family is quite tech-savvy. Amina is using a wearable technology to monitor her glucose level and Brian likes to use his personal health management app to check his health status. Their house is equipped with sensors (sleep, nutrition) and they check regularly their health parameters through connected devices.

• Encouraged by their GP, the Yee family will drive the Malaysia and use the dedicated app to get the information they need to be safe during their journey. While in the grandparents' house, they will be able to use the car as a health monitoring room and verify their different individual parameters.

• The app will also collect information about Brian's physical activity and provide him with some target goals, as Brian is keen on being challenged. His GP will also use and benefit from this information, ensuring that Brian is following the specific recommendations set for him to slow down his chronic condition. • John has two main professional activities in Singapore: driving cars on demand and working part-time in a bar in the CBD area. He is always on the move, mainly 54 3.4 Use Cases in his car but he also uses public transport.

• John suffers from a respiratory condition due to allergies and high sensibility to air pollutants. Living alone, John needs to continue working and live independently.

• John is concerned about the potential impacts of air quality on his health and he wants to make sure that he manages well his condition, especially in hazy time where air pollution level could be very high.

• Through a dedicated app on his smartphone, John will be able to check air pollution in real time and determine whether to use public transport/taxi or walk or cycle to the bar where he works.

• Since he is also driving a lot, John also wishes to be informed directly in his car about the air quality and get some information on which areas to avoid, where to park and which route to take. The dedicated app will connect to the car assisting system to provide John with navigation recommendations in case of pollution peak. This system will be connected to the public authority's smart mobility management system in order to follow the recommendations set by the LTA.

• When a degraded air condition is detected, John's car will immediately activate the air filtering system. The in-car embedded monitoring system will also provide him with reminders on when he should stop, do some light exercise or even rest for a while, through coaching exercises that he can do at home in case of pollution peak. Keywords: Respiratory diseases, air quality, lifestyle coaching, pollution, smart urban mobility, connected cars, navigation

Rules for Concurrent Activities

By design, the default model allows to decide what activity the user is currently performing. This decision is taken in every reasoning cycle. If the decision differ from the previous, the former activity is finished and the newly recognized activity starts and becomes current. When the user is detected doing something else, the object of the triple user isBelievedToDo [Activity] is updated.

A reflexion has been made on concurrent activities -the possibility of detecting multiple activities hapenning at the same time. It implied the change in the update mechanism. Instead, of a replacement of the object, a new triple was added. A conceptual test, provided in Source 5 have been carried out, however no conclusive results were achieved. The main concept of multiple activities is possible in the reasoning with some modifications of the controller that handles the KB.

Rules for Mobility

A special case of rules are designed for Moover application, presented in detail in section 5. These rules, Source 6 have a different scope and focus on fusion of sensor data from public sources (weather, air quality information) and user's profile.

Figure 18 focuses on the cases of rainy weather and walking. It illustrates a path from a piece of information to a decision, explaining the role of different types of rules.

###################
# object of {"weather" "hasDescription" object} contains a string {hom:weather qol:hasDescription [ string:containsIgnoringCase "shower" ]} => {hom:

weather hom:is "raining". ubi:n3store ubi:updateObject {hom:weather hom:is "rain"}}.

{hom:weather qol:hasDescription [ string:containsIgnoringCase "rain" ]} => {hom:

weather hom:is "raining". ubi:n3store ubi:updateObject {hom:weather hom:is "rain"}}.

# Weather that is OK {hom:weather qol:hasDescription [ string:containsIgnoringCase "fair" ]} => {hom:

weather hom:is "fine". ubi:n3store ubi:updateObject {hom:weather hom:is "fine"}}.

{hom:weather qol:hasDescription [ string:containsIgnoringCase "cloudy" ]} => {hom:

weather hom:is "fine". ubi:n3store ubi:updateObject {hom:weather hom:is "fine"}}.

{hom:weather qol:hasDescription [ string:containsIgnoringCase "overcast" ]} => {hom:

weather hom:is "fine". ubi:n3store ubi:updateObject {hom:weather hom:is "fine"}}.

# Match haze, hazy

{hom:weather qol:hasDescription [ string:containsIgnoringCase "haz" ]} => {hom:

weather hom:is "fine". ubi:n3store ubi:updateObject {hom:weather hom:is "fine"}}.

{hom:weather qol:hasDescription [ string:containsIgnoringCase "fog" ]} => {hom:

weather hom:is "fine". ubi:n3store ubi:updateObject {hom:weather hom:is "fine"}}.

# Dangerous weather conditions takes over "fine" or "raining" {hom:weather qol:hasDescription [ string:containsIgnoringCase "heavy" ]} => {hom:

weather hom:is "dangerous". ubi:n3store ubi:updateObject {hom:weather hom:is " dangerous"}}.

{hom:weather qol:hasDescription [ string:containsIgnoringCase "thunder" ]} => {hom:

weather hom:is "dangerous". ubi:n3store ubi:updateObject {hom:weather hom:is " dangerous"}}.

# To be discussed {hom:weather qol:hasDescription [ string:containsIgnoringCase "windy" ]} => {hom:

weather hom:is "windy". ubi:n3store ubi:updateObject {hom:weather hom:is "windy"}}. An ontology together with a set of individual instances of classes constitutes a knowledge base.

Our reasoning is based on an ontology and expressed in triples describing the knowledge base containing the information about the system status instantiated for each 58 3.4 Use Cases participant. The rule-based system performs an inference over these triples (subject, predicate, object) which connect different concepts. An example of instantiated knowledge base is depicted in fig. 19. Organisation of the data in triples provides a more flexible way of handling models: it describes the environment, and allows to integrate data from multiple sources. The challenge lies in algorithms that have to be described in a different way than usual procedural programming that tells to computer what to do. Instead, we describe knowledge (input), conditions restrictions (rules) and select the output (query), thus the reasoning engine provides us with the result in the defined form.

As a part of the contribution of this thesis, the model of the ontology classes fig. 20 has been built upon the previous home and indoor oriented ontology. This version provides an extension to outdoor environment. The proposal takes into account the targeted frailty conditions such as type II diabetes and asthma. This ontology focuses to mobility solutions as the main premise of this research project is the positive effect of active mobility towards a better health as explained in section 5.2.

Execution of the Reasoning

First, when an event happens the sensor controller registers the kind of the event and the time (according to its clock) then the event is transmitted. Figure 21 represents the delay between the instant when the gateway time-stamped an event arriving from a sensor, and the moment of the reception by the UbiSmart server. This delay can grow considerably in case of network disruptions. Both time-dates are stored in the UbiSmart database in columns "date" and "createdAt" respectively.

The whole process is summarised in fig. 22. First, (1) an event e happens (pictured in "produced events" track). The information about it is transmitted through the system and gets to UbiSmart platform with a relatively small delay, usually in order of milliseconds (2). This interception of the information is visualised on the (1) event observed at t0

(2) intercept event at t1 e Time t0 t1

Produced events

Interception track

Figure 21: There is a delay between an event and arrival of information about it.

"interception track" as a black dot. An interception automatically triggers (3) a reasoning cycle that is indicated by a vertical bar. Note that the event is taken account of into "intercepted events" track where are shown events the system is aware of. The event that triggered the reasoning cycle has a special position -as all previous events were accounted for, only this event is (as of current system) considered in the reasoning process. As a sample output, the system decides that the user is doing an activity A (4) that this event triggered. The duration of the activity is from the moment when the event occurred till "now" as observed by the system. The last activity is memorised as "current activity" as it is probable that it will be extended. This information is persisted and can be retrieved as well as all the intercepted events for further analysis.

Next reasoning cycle can be triggered by either another event or a special timeout, called "clock event". Figure 23 shows both cases and illustrates how a clock event extends the current activity. Alternatively, the clock event may stop a current activity due to a rule that defines maximum duration of such activity. For instance, sleep for more than 24 hours. Another possible case is when a anomaly is to be detected. For example, if we decide that the hygiene activity should not last more an hour, the clock event may trigger a notification that something is wrong and the person might need help. Clock events are not kept track of and therefore they do not appear in the event list (visualised by the service "senslog").

System Components

The system, which in simplified form presented in fig. 24, comprises many elements that I will present here. Their integration is explained in the following section. Conceptually, we need to make a communication link between the sources of data and the processing component, create visualisation or a specific interface that will provide an overview or will present the expected information in an adapted way.

Main building block categories can be summarised as resources that provide some

(1) event observed at t0

(2) intercept event at t1

( Figure 24: Ubismart platform software architecture data, user-interfacing components that ensure human-machine interaction and in between connecting bricks that provide internal backend services to other components and link them together.

We can also see a balancing between load between our server machine and the user's client machine that is depicted in fig. 25. This processing balancing is easier as the platform uses Javascript programming language on client as well on server side.

Data Sources

Static or rarely modified resources, such as the list of train stations or paths available for cycling can be accessed via a simple download and integration in the codebase.

Dynamic resources are typically accessible through an API. Usually the service provider provides an endpoint URL. The server replies to an HTTP requests directed at this endpoint with the requested data in JavaScript Object Notation (JSON) or XML. The request can contain parameters (geolocation), optionally authentications tokens, depending on the level of security and restrictions of the service. Examples include information about current Air Quality Index (AQI), nowcast (weather forecast for next 2 hours).

Figure 25: Server -client load balancing schemes for processing data for its presentation. Highlighted region indicates where our platform is situated.

The same approach is used in the case of Fitbit devices. Even though Fitbit device is paired to a smartphone, the data cannot be directly accessed by this smartphone. Instead, Fitbit device encrypts the data and relies on the paired smartphone for its transmission to Fitbit server. The smartphone then queries the server through an API for updates and only then downloads the data. In this way, Fitbit server has control over the data and can augment the raw information with its own analysis. This feature implies that an Internet connection is required to get updates from the tracker.

Some data sources are provided locally from the smartphone. The dedicated smartphone application component then sends the data to our server. For example, data from sensors in the mobile phone are collected or preprocessed activity recognition by a library provided within the Android framework.

A third party open source applications was used to detect beacons. OwnTracks application, available for iOS and Android platforms has a built-in support for MQTT communication. A list of the known beacons and an MQTT endpoint makes the application ready for deployment. Thanks to the work of Firas Kaddachi, our platform can monitor when the device enters or leaves the proximity of any beacon.

Sleep mat provides raw data output via a wired connection. It consists of a timestamp and light intensity value. This signal is processed directly on the gateway (Raspberry Pi) and also stored for an offline analysis.

Connectors

The choice of the communication protocols was adapted to the support and the data type. Web interface features secures Hypertext Transfer Protocol (HTTP) access.

Within the website, asynchronous data retrieval uses JSON format for information exchange. Message Queueing Telemetry Transport (MQTT) had been chosen for message exchange between the gateway and the UbiSmart server. Main reason being shorter headers in the messages compared to HTTP or XMPP protocols that were also considered. MQTT presents a publish-subscribe paradigm. Emitter (sensor) publishes its messages to a topic containing its identifier. The server subscribes to the topics of all relevant sensors.

Maintenance

Maintenance tools are an essential part of the system design. The physical access to the hardware during a deployment in resident's homes is restricted, remote access has been established.

As the internet connection was unreliable during the deployment, I developed methods for data retrieval from log files. In this way, the events could be reconstructed as soon as we accessed the gateway. Main causes of the event loss were unavailability of the connection or errors during the reception on the server side.

For an optimal use of the limited memory in the SD-cards, I designed a service for truncation and compression of the voluminous sleep data. In several cases, we could observe memory corruption in SD-cards and based on previously mentioned log file analysis, forensic methods were designed to retrieve the logged data.

To aid the maintenance and determine when a problem occurred, I designed monitoring services for real time feed into the instant messaging application to provide immediate notification about incidents.

Conclusion

This chapter presented the main design features of our UbiSmart platform. Its main challenges belong to software engineering domain. However, some research potential can be seen in practical implementation. The most importantly, moving from indoor monitoring to outdoor is crucial to the development of the platform. The use cases for mobility are presented and semantic framework explained. The contribution of mobility rules is detailed in this section, as well as other aspects that are more of a practical than scientific interest, e.g. maintenance. In a short summary, UbiSmart could be presented a platform that uses sensors available as consumer electronics. The sensors capture events and report them via a gateway UbiGate. The structured sensor data is then relayed from all gateways to the core component -the UbiSmart server. Using MQTT protocol, the original data is received, stored, processed and injected in a reasoning cycle. The reasoning is constructed from two models: abstract and instance. Abstract model contains general rules valid for all situations and is initialised at platform launch. Instance model captures the specific user's environment and maps their interactions through services, it is also where the current sensor readings are made available. Together, they make a knowledge base on top of which, during a reasoning cycle, the rules are executed. The last component in the data flow is the service provisioning that serves the data to the end-user. It is basically a web interface or a mobile application.

This chapter details my contribution to the platform's ecosystem, mainly concerning new extensions of services, programmable interfaces, control interfaces, and performance enhancements. The most recent contributions make the platform up-to-date 4.1 Introduction and aligned with higher security and reliability expectations.

Following sections describe the outputs of the process of building strong and relevant user requirements, introduce the development strategy (modularity and agility) and present overall deployment structure. Given these elements, I will be more specific about the hardware architecture in terms of deployed sensors, such as the sleep mat, Bluetooth beacons, contact and motion sensors, wearables, smartphone, and Application Programming Interface (APIs).

After the hardware overview, I will detail the required software implementation plan, specifying the adopted technologies and choices. A comprehensive review of all contributions and actual implementation of the platform will be made, focusing on the development of backend and frontend services, from data replay algorithm to user's visual interfaces, and live activity recognition analysis.

The Platform

The previous chapter described the mechanisms at work and the building blocks for achieving the aims of the platform. This chapter will explain the path that lead to the current system illustrated in fig. 26 and its software architecture depicted in more details in fig. 24. As illustrated, the system integrates inputs and outputs like many other smart home platforms. The difference is in the use of the semantic web technology that integrates all the data sources into a knowledge base. This knowledge base serves as a support for logical inferences based on series of rules. The purpose of this platform is centred around the monitored user. The definition of required features revolves around the user and optionally their caregiver. For the monitored person, the system must be transparent and not hinder the everyday life. The main purpose of the system is to increase the user's well-being. Two ways have been explored: providing cues to the user, and giving a concise overview to the caregiver. We refer to these stakeholders as the main stakeholders as they are the most important in recognizing user's well-being.

One of the new features was an experimental "happy button" as the mobile application with very simplistic interface fig. 27. In contrast to a panic button that indicates a situation of distress, this application was offering simplified well-being monitoring. Our team encouraged the participant to use the application as many times as they wanted. No automatic notification was implemented to avoid annoying the participant. As illustrated in fig. 28, in average, we received one feedback per day. The most of the events indicated a positive feedback, confirmed in the interview with the participant.

The users' contributions during the development were iterative and continuous. The system was first presented to the caregiver on a portable device (a tablet)

Development Strategy & Structure

This section describes how the platform is composed from several repositories and what other tools than a version control were used in the development process.

Modularity (Git Structure)

UbiSmart has been designed as a modular platform using a mechanism of version control -git, in particular hosted by the service github.com. Figure 29 presents how an instance of UbiSmart platform can be composed from the building blocks -each residing in its own repository, independent of the main code base. For one kind of components, there is one repository and each component of its kind (e.g. ubiservices) has its own branch within the repository. On a file system level, this architecture choice means that a UbiSmart instance directory has inner directories containing code from branches of ubiservices, and another directory contains files from greymatter repository. These repositories are being replaced or inserted upon request from the administrative web interface -during the runtime. In detail, the Version Control System (VCS) git, makes a clone of the most recent or specified version (i.e. commit) of the branch and repository. The newly replaced or added code is then ready to be used, as the knowledge base is aware of the new available services.

Agility (Approaches, Meta-knowledge Management)

Tools that aid the development fall into these categories: communication, productivity, planning and incident reporting. Communication tool Slack had been used for coordination between teams in Singapore and in France. The main advantage of this messaging service is that it was created for developers and has some crucial advantages over popular instant messaging applications (such as WhatsApp, iMessage, Google Hangouts, IRC, XMPP): There is an API for sending messages and has the ability to create custom commands (entered as a text message prefixed with a slash "/"). A contribution that has been made was described in 4.5.5, it was augmented by automatic updates and reporting about the status of currently deployed assets.

Agile development strategy includes a planning of contributions. For this task, webbased Pivotal tracker was used. The system of stories allows the follow-up of a task. The task's life cycle starts when it is classified as residing in the column icebox, it can be moved to backlog (tasks to be scheduled) and when it is started, to the current iteration. Each task can be evaluated to have more or less "points". They determine how complex the task is relatively to other tasks. After completing the For a more fine-tuned planning and organisation, service Trello was used. Inspired by Japanese organisation style kanban, it can be used as a signboard for setting the priorities, where the tasks travel from one side of the board to the other as they are being completed. UbiSmart can be seen as an ecosystem. Figure 30 shows the wired and wireless connections between physical devices connected to UbiSmart platform. They allow gathering the information, processing it and serving to clients. The number of integrated devices is growing: Integration of Juvo sleep mat, Z-Wave sensors, Bluetooth beacons, UnaBiz sensors and mobile applications. Integration of these various devices and related data collection is a part of contributions within the scope of this thesis.

Hardware Architecture

In the following section, the relative importance of these components, their configurations and contribution to the system will be discussed, in addition to the links and protocols for information exchange.

The selection of the components was made with regard to the price, maintenance costs, having in mind an easy-to-deploy and economically efficient system. Raspberry Pi Raspberry Pi is a pocket size computer that is commonly used in IoT applications because of its small size, and ability to run Unix-like systems that eases portability of algorithms. It is a single board computer. Release 2 has the same layout as the release 3. Both types were used in our deployments. The major differences between them include wireless network support and higher power consumption for the Raspberry Pi 3 (fig. 31).

Figure 32: Micro-SD card Memory card We are using 16 GB micro-SD cards fig. 32 as the memory medium for Raspberry Pi computer. It is the storage for operating system as well as for data. We use 4 GB micro-SD card for sleep mat data backup storage. SD cards in Raspberry Pi computers are prone to problems with file system integrity. The most common problem observed in the Raspberry Pi based file system is that files contain a series of null bytes inside regular files (e.g. shell history). This problem seems to be linked to power supply of the Raspberry Pi and occurs on Raspberry Pi 3 only as of our experience.

Mobile router In 2016's deployment, the network communication was performed via an Ethernet cable connected to the resident's router. Network connection was very stable. However, for the second and the third deployments, our participants did not have any internet connection so we provided 3G modems (mobile routers) Huawei E5330Bs-2, depicted in fig. 33. These modems contain a battery and provide two modes of connection (USB modem and WiFi). The main disadvantage is that when they switch off, it is only possible to switch them back on by pressing the physical button. That case happens when the system is off for more than a few hours (e.g. blackout, departure for a vacation). A specific subproblem is topping up a SIM card in the modem. It is advisable to find a deal with a local carrier, which was not possible for our deployments in Singapore.

Hardware and Software Configurations

Communication Protocols

The system uses multiple protocols to convey the information between respective components. In particular, Hypertext Transfer Protocol Secure (HTTPS) protocol is used for communication between user interface devices and our server. Additionally, HTTPS is used for gateway registration (when adding new indoor monitoring unit to the system). The exchange is secured by freely available certificates provided by the service of Let's encrypt.

The protocol HTTPS is used in every website that insures a standard protection of the user data against reading by a third party. Based on SSL (Secure Sockets Layer), it provides a cryptographic guarantee. However, for the use in sensor networks and particularly smart homes, the protocol is too heavy, mainly because of the large headers that are exchanged. This protocol is still used to deliver the content to our users. A very important part is the trust of the domain certificate.

MQTT MQTT is a machine-to-machine (M2M)/"IoT" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.

It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. It is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.

The currently used version is 3.1.1 but as of April 2019, the version 5.0 of the MQTT protocol has been published. The new features include a better error reporting, load balancing, metadata in the header, expiration of the messages Better error reporting is important for user experience as the user can be handed the decision whether the information should be sent or it is no more valid.

API

Our sources of data range from personal data provided by companies to governmental services. A considerable amount of data sources is listed and described in data.gov.sg webpage. They are organised in sections: economy, education, environment, finance, health, infrastructure, society, technology, transport. According to the full listing as of July 2019, there are nearly 2500 datasets. Several datasets consist of KML geographical data, comma separated values (CSV) tables, or direct API providing the data in JSON format.

Fitbit Having an account on fitbit.com, the user gets access to their data. The raw data is not directly accessible. In order to explain what data is available and how to get it, there is some useful background information the process.

First, the raw data is encrypted within the device and in this form, it is transferred to a mobile phone or another Bluetooth enabled proxy device running a software. For elderly people who do not have any smartphone or computer with which they could pair their tracking device, I installed software galileo that is even used by the official application to transfer the encrypted data to their servers. The mobile phone cannot read the encrypted information and only forwards the encrypted file to Fitbit servers. Servers process the data and make it available. Thereafter, the mobile application downloads the prepared aggregated and processed data. Our system interacts with Fitbit servers via an API.

It works via a notification service and a quota. Our server-side application is notified by the Fitbit server and then we are able to download the wanted information: about sleep, step count for each day and other information

Weather forecast https://api.data.gov.sg/v1/environment/2-hour-weather-forecast provides the expected weather condition within 2 hours. Compared to the current observable weather, it allows a near future projection for possible activities.

Smartphone

Smartphone has been used very extensively, as it is becoming an inseparable device from its owner. During this work, the first use was to serve as a feedback and questionnaire device. This device was planned to be used to perform activity detection (see section 4.6.6), position detection relative to points of interest tagged with the Bluetooth beacons (ubitracks/owntracks), it was used by caregivers or participants themselves during the indoor deployments, and as a support for the mobility centred application.

Sleep Mat

Specific equipment for sleep monitoring and monitoring of vital signs has been developed by JUVO, a company working providing the access to raw data and allowing us to apply signal processing algorithms. The device is a microcomputer sending light signal through an optical fibre zigzagging over the whole area of the sleep mat.

The microcomputer captures the intensity of the light at the other end. The inner surface of the mat in contact with the optical fibres has a texture that makes the increases the variation of the light intensity when a pressure or any oscillation is applied. Figure 35 depicts the sleep mat and the micro-controller.

Figure 35: JUVO sleep mat based on optical fibre micro-benders, used to monitor presence of a person and their vital signs through a mattress.

Software Implementation (Backend)

UbiSmart is a platform on which most of my contributions has been made. It was created by Thibaut Tiberghien and his collaborators in 2015. Its details and technical choices were presented earlier in this chapter. This section focuses on my contribution to the platform's ecosystem, mainly concerning new services extensions of services, programmable interfaces, controlling interfaces, and performance enhancements. The most recent contributions make the platform up-to-date and aligned with higher security and reliability expectations.

The purpose of the platform is to collect quality of life indicators, using them to detect risky situations [START_REF] Bellmunt | [END_REF], Sadek et al. 2017], long-term evolution [START_REF] Kaddachi | [END_REF], and to enhance the quality of life by an intervention. The main monitored target group is the ageing and frail population, although caregivers can benefit as well [Mokhtari et al. 2015].

To achieve its goals, the platform UbiSmart makes use of standard commercialised sensors producing events, a gateway UbiGate that relays the structured event data to the main component -our server written in Node.js. Eventually, notifications are sent to other devices as part of service provisioning. The reasoning is situated in the server: Incoming events are stored in a database, translated in triples using Notation3 format, and queued to be processed within the reasoning cycle. The connections within the platform are shown in fig. 36.

UbiGate

Framework "Sails"

For the main frame of the web application and interconnect different components, Sails.js framework was chosen. It is a framework programmed in Javascript, in particular NodeJS -which is server-side javascript environment and language standard that evolves together with ECMA Script.

Sails.js provides several advantages for prototyping but also for a project that evolves. It provides database connectors as middleware, so it is possible to design the application without having a particular database in mind and more focus on the structure of the database. For evolution of this structure, there is another useful mechanism -migrations. Descriptions of the database are stored in a JSON format and provide the information about what structure has to be created and what has to be destroyed if we want to undo this modification to the database. Therefore, every file can be applied to the database, keeping track of what was created when, in which version and furthermore, writing these description files correctly means that we maintain the database structure and coherence.

Another aspect of the Sails framework is the REST API readiness. REST interface enables the manipulation of objects in the database through well-known basic operations (GET, PUT, POST, DELETE) that were defined in the HTTP protocol and allow for a easy deployment as the semantics of these operations is clear and portable to other uses. The generation of the endpoints that are providing these services is automatic and can be restricted using specific policies (e.g. administrators of the platform can perform any action on any object, although users can only see their own data).

A very useful feature that allows to build interactive applications on the web is called websockets. The technology enables the creation of a direct connection between server and the client (browser). In this way, the exchange is much faster than the previously used AJAX methods. Exchanging the data in both directions is particularly useful when it is needed to communicate not only by sending the data to the client but also from client to browser. A typical example of usefulness of this technology is a highly responsive system that the user controls and receives the data back.

It is worth noting that Sails.js is not the only framework supplying all these services and during the years, a lot of criticism has been outlined about this particular framework, criticising several components, especially the Waterline ORM and some architectural choices. Meanwhile, the framework underwent a refactoring in order to get the version 1.0. This version changes several interfaces and therefore a very thorough upgrade process has to be followed. In order to be compatible with the most recent versions of NodeJS -and thus keep the platform sustainable, I started the initiative to transit towards the new version of Sails.JS framework.

Gateway in Python: "UbiGate"

The gateway is the software component of the system that allows us to collect the data from nearby sensors and forward it towards our main platform which integrates all the data and stores them permanently. Our gateway is called "UbiGate" and is written in Python. It runs on a Raspberry Pi SBC (section 4.3).

This software has a structural system of plugins that provide specific services according to the technology from which we get the data. For instance, Marmitek sensors using a historical X10 protocol had been implemented before I started to work on this project. The main code of the gateway provides communication via MQTT and is able to provide password-protected communication. I mainly contributed to the maintenance and enhancements of the gateway code, adding the ability to transfer the data from Z-Wave sensors. This particular solution involves Domoticz platform that operates the sensors and forwards the data within the machine to our gateway. My solution transforms the data from one format to another and seamlessly delivers the data to UbiSmart. As the format was linked to Marmitek sensors, the plugin respecting the original format was named "Domoticz_to_Marmitek".

Domoticz: Z-Wave Configuration Centre

Domoticz (fig. 37) is an open-source standalone platform that integrates various technologies and provides unified outputs, in particular, using MQTT. It provides This platform is integrated in the UbiSmart as a bridge between sensors and the gateway. In particular, it makes use of OpenZWave9 library that handles devices implementing Z-Wave protocol. As Domoticz is an open-source software with a community, it is kept up-to-date with recent technologies as well as the most popular and older technologies.

The necessary operations during a deployment are as follow: add node to the Z-Wave network, and track the devices to be forwarded to UbiSmart. These operations should be automated in the future. Currently, the ssh tunnel being established between a cloud server and the Raspberry Pi running the gateway and Domoticz allows us to use Domoticz remotely.

SSH Reverse Proxy: "ssh-piru"

I developed a systemd service that runs in Debian Linux so that the Raspberry Pi computer connects to our cloud server and exposes its ssh on a port specified in the configuration. The security is insured by asymmetric public-private keys that authenticate these connections. The Raspberry Pi computers contain a private key having is public counterpart stored in the cloud server. Thus, the Raspberry Pi computer can authenticate in the cloud server and expose its port 22 on an arbitrarily

Figure 38: Reverse proxy for remote connection to deployed units chosen client port of the cloud server (e.g. 37365). The service maintains this ssh tunnel, equivalent to the command ssh -R 37365:localhost:22 CLOUDSERVER. The effect is that anyone allowed to connect to the port 37365 of the CLOUDSERVER host will transparently connect to the Raspberry Pi computer as illustrated in fig. 38. This approach is useful in the cases when the administrator is not on the same network and the Raspberry Pi does not have a public IP address, which is usually the case unless a special configuration of the router allows port forwarding (which is the same mechanism as shown here but provided by the local equipment). In our case, it works even when the internet connection is provided by a 3G router.

Figure 39: Forward proxy for MQTT in restrictive networks A particular use of this approach of tunnelling is useful in environments filtering several ports, i.e. not allowing connections on ports other than 80, 443, 22, and a few others as a security measure. This policy is often deployed in some institutions and free hotspots to limit misuse of the internet connection. However, as our MQTT messages circulate on port 1883, it is necessary to create a tunnel that will forward the data to our server through a different port. In practice, we create a tunnel listening locally on an arbitrary port (e.g. 11883) and we will forward the communication through a tunnel established via port 22 that is available. In practice, it is expressed as the following invocation of the SSH command: ssh -L 11883:localhost:1883 UBISERVER, schematised in fig. 39 4.

Monitoring of Deployed Gateways

Slack is an instant messaging service. It aims at business communication and collaboration and supports automation of tasks. Unlike the popular broad-public platforms (e.g. WhatsApp), it provides a free API for scripting. The communication is organised in channels, similar to Internet Relay Chat (IRC), where users publish their messages for others to read them. Direct messages are supported as well.

The API offers two basic features: message publishing and command hooks. First, the straightforward "incoming webhooks" functionality textbfpublishes a message to a channel (with optional interactive elements). Using the API, any computer with the right credentials can send a message. Incoming webhooks are a way to post messages from external sources into Slack. They make use of normal HTTP requests with a JSON payload, which includes the message and a few other optional details. Message attachments can be included to display richly-formatted messages.

It also can contain interactive buttons. When a user presses a button, the specified signal is sent. This is the very principle of the second feature: command hooks. Also inspired by IRC, messages starting with a slash are not sent into the current channel but they are interpreted as a "slash command". The configuration of the API associates the command with a URL. Every time the command is invoked, Slack server sends an HTTP request to the specified endpoint URL.

I used both features to implement a monitoring environment within this instant communication tool. The main advantage is that all work related notifications and messages are concentrated in a single interface, independent of private communications.

The monitoring service runs in the same cloud based machine as a UbiSmart server but for simplicity of implementation (and possible externalisation), it was implemented as a set of shell scripts: slack-monitor-connections.sh, send-to-slack.sh, slack-monitor-4h.sh, slack-monitor-info.sh.

The script send-to-slack.sh is a simple utility that sends the message provided as its parameter. A long running task can send a notification that it finished, e.g. replay process. Or another event can trigger the notification, e.g. the gateway connects.

The script slack-monitor-4h.sh provides an information summary about measurable parameters of each listed gateway. This service connects to each of the gateway machines and queries for occupied disk space, occupied RAM, core temperature, voltage, uptime, count of currently logged in users, CPU load average (1 min., 5 min., 15 min.), occupied swap space, and a list of deployed UbiGate plugins. All this information is then reported in #status channel. As its name suggests, the task is initiated every 4 hours and its result is depicted in fig. 40(a).

The script slack-monitor-connections.sh queries current Secure Shell (SSH) connections. It compares them to the previously retrieved list. The difference is reported in #general channel with the message indicating whether the device appeared or disappeared from the list. An example is shown in fig. 40(b).

The script slack-monitor-info.sh provides the URL endpoint for Slack slash command /info. When a user issues this command inside their messaging interface, a request is sent to the URL http://martin.ubismart.org:9876 (the port has been modified). The shell script listens on the specified port. When it receives the request, it replies with the list of currently connected units and a message indicating to the user that his request is being processed. When it is done, a message as defined by slack-monitor-4h.sh is sent to the channel #status and all allowed users (technicians) can see it. Figure 40: Monitoring system using Slack as a medium for information about the deployed units

Various Supporting Scripts and Environments

In addition to presented scripts using Slack, there are other contributions in order to make the management simpler: screen environment for Raspberry Pi, SMS service for 3G routers, Moover serving webserver.

GNU Screen is a well known multiplexer for UNIX-like systems. In simple terms, it provides multiple virtual terminals within one terminal on remote or local connection. It features simple window manipulation functions, easy switching between virtual terminals. It also persists in case of network disconnect and it is possible to reattach to the previously detached session. The commands continue running when "detached". Also, multiple simultaneous sessions are supported so several clients (users) can see the exact same environment. Figure 41 features in the left bottom corner: the deployment number (port indication where it exposes ssh-piru service), house number that corresponds to the number of associated house within UbiSmart environment, gateway number that is the identifier in the UbiSmart of this Raspberry Pi, an indication that this screen is running on a Rasperry Pi. The standard status bar continues, presenting the list of current virtual terminals (0$ * zsh is the one currently selected and another one is named, shown as 1-$ buffer.json. Reading SMS from the router is particularly useful when it is necessary to query the balance on the account of a prepaid card that was deployed on site. Following the consumption of the data is performed via mobile carrier application running on any smartphone. In order to prevent unauthorised use, when identifying with a phone number, the application sends a verification code to the verified phone number. We need to type this code into the carrier's application to access the information about current plan and remaining balance. A standard procedure would be to use a third type of ssh tunnel -dynamic port forwarding which basically behaves as a SOCKS proxy. Then, configuration of the web-browser to use this proxy to access local address 192.168.8.1 as seen from the Raspberry Pi, where the router exposes its web interface for administration. The user needs to log in with administrator's password.

Only after that, SMS text messages sent to the phone number are available. The script reading SMS messages is a way how to avoid the heavy setup and runs directly on the Raspberry Pi. It accesses the webpage of the router, authenticates and extracts last SMS messages from the HTML website, then logs out and outputs the messages in standard output.

Replay

The service named "replay" was created to address two problems: delayed events and testing different versions of rules.

First, problem of delayed events occurs when some events were not taken into account by the reasoning process in real time. This state of the system was reached in some specific cases, notable network connection issues (see section about 3G modems section 4.3). Another recurrent issue was the overwhelmed UbiSmart server when it received too many events and they started to queue. It is also linked to another problem that was discovered during testing of this service.

Second, testing new rules and potentially ontologies is a process that has to be tested on real data and until now, the system was able to assess only the data processed in real-time. The proposed component allows the research to reuse and to compare different configurations, and also possibly introduce automation in rules creation (with a feedback loop)

The proposal suggests to return to a certain point in time where the reasoning was not influenced by the missed events -initial implementation goes back to the start of the reasoning process. A replay action is performed -every event is scheduled and arrives setting the current time to the time when it was produced. This way we obtain the adjusted timeline in addition to the original timeline. The corrected timeline provides all inferences and in particular activities as their visible results.

The proposal argues to keep two timelines -the one that was inferred in the real time and the most accurate one that had all amendments that were made during all replay processes. The function of the replay is illustrated by fig. 43. Creation of a new branch of the timeline for activities. It compares to the standard reasoning process described in fig. 22. A more complex example would contain clock events (as in fig. 23) and their simulation in replay mode.

Service Implementations (Frontend)

Integration & Aggregation

The interfaces letting the administrator to manipulate the configuration are naturally part of the existing code base. Notably, home description service provides a way to describe the living space in terms of sensors and rooms and is central to deployment of the smart homes for elderly people.

Event-statistics

In order to get a bird's eye view of the performance of the different houses, I contributed a service summarising the number of events per home and per day depicted in fig. 44. This allows to see variations in time for one home. We can easily notice when a home usually has 800 events a day and this number falls to 43. The problem usually is a sensor that is no more powered. Either because the battery is too weak or the sensor was unplugged from the power supply.

A very particular case of this type of observation is when the number of events drops to 0. That is the case when the gateway is having an issue (either with connectivity, or running out of memory).

It is also possible to notice differences between homes. Supposing that all devices work properly in the compared spaces, much more events may indicate that the Figure 43: Replay service creates an alternative activity timeline with all currently available events, triggering the reasoning process for each event and for each clock event that would occur in a gap between events. person spends a lot of time sitting or lying on the bed. This logical induction can be made because the bed sensor sends (as of current deployments) events regularly when the person is on the bed. Similarly, extremely low numbers indicate malfunction of the bed sensor. This service's current pitfall is the lack of time-zone management and the events are partitioned into days according to UTC. The main issue with this service was the lack of good quality data. The reasons, along with already mentioned power supply issues were habits of our participants.

Due to the all-year hot weather, some participants admitted not sleeping on the bed under which we placed the sensor. They rather prefer to sleep on the floor on a light mattress. This floor mattress was stored on the bed during the day. In this case, the manipulation of the bed was captured in the evenings and in the mornings. Hence, despite the lack of sleep information, we could get a secondary information about when the light mattress was manipulated. Senslog This service summarises the events that happened within a chosen time frame. It is particularly useful for debugging and testing but caregivers showed interest in viewing this data as well. The former version of this service displayed the data in real-time within time frame of: 10 minutes, 1 hour, 3 hours, 6 hours, 1 day, or 7 days. I enhanced it with the navigation into the historical data. A view is shown in fig. 46.

A part of senslog, "signalviz", provides a visualisation of numeric measurements. ??

shows the visualisation of 48 hours of temperature and humidity measures. This feature is useful for observation of correlations between different sensors. For example, hygiene could be detected using relative difference of humidity between living room and the bathroom. We can observe that sudden increase in humidity does not necessarily indicate showering or cooking activity. These changes can be also due to a change in weather conditions.

Intervention

Intervention means a number of communication actions received by one or more stakeholders, as illustrated in fig. 50. In this sense, stakeholder is the monitored person (elderly person, user interested in quantified self), formal (senior activity centres and community centres staff and volunteers) and informal (family relatives, friends and neighbours) caregivers. Certain communication channels require a certain degree of technology acceptance and skill (e.g. if we choose to send messages via one of messaging platforms). Therefore, choice of adapted technologies is important and has to take into consideration personal limitations and preferences. Communication channels Messages can be delivered to the user, providing information such as useful tips, training opportunities, community events, and the information together form a baseline communication channel. Local information, motivation messages and local weather conditions can be added to this first block of communication. In Singapore, considering the diverse ethnicity groups, simplified English together with illustrations have the highest success rate of understanding. On-purpose communication channel then refers to the visualisations, metrics and messages produced by the system to enable the user to interpret the data. This channel can deliver several types of messages such as encouragements, warnings and risk messages. The encouragements messages aims to reinforce positive actions performed by the user or encourage a positive action. (System positive activity is likely more performed: "You are doing really well, keep going!"). The warning messages aim at highlighting a particular aspect of the monitoring, resulting in stopping, starting or continuing a specific behaviour that might be risky or that might induce a decline in the overall Quality of Life (QoL). Risk messages are triggered in the case of signs of strong and serious decline or negative change of behaviour. This decline can be observed on multiple parameters such as a drop-out from attending social events (from senior activity centre's data), a rapid decline in performing basic ADLs such as the ability of room transfer or the ability to cook food during usual meal times, or a decline in sleep quality and sleep related issues.

Knowledge

Development of the knowledge base encompasses the construction of several subsystems: activity recognition, uncertainty, beacons in point of interests, mobility recommendation, concurrent activities.

The main feature being the recognition of activities, this subsystem shaped the architecture of entities taken into account. The reasoning compartments follow users' living space and as such, each "house" has its separate reasoning environment, i.e. knowledge base, that evolves independently of others.

In currently used implementation, the uncertainty measure was not included. As part of it, the score system had been developed within the reasoning. The score system is currently used to decide which activity to choose if conditions for more than one were met. Another resulting behaviour is that when multiple activities were attributed very close score, no activity is detected.

A special attention was brought to Bluetooth beacons that mark Points of Interest (POIs), places that provide a crucial service or have an importance in community life. These were selected in Singapore case: outdoor exercise corner, hawker centre, wet market, bus stop, lift lobby (outdoor), senior activity centre, community centre (to read newspaper). A smartphone equipped with beacon-tracking application configured with the list of deployed beacons stores the entry and exit times in these zones. This information is transferred to the platform as regular events. Similar to the events produced by home sensors, these events are processed with the reasoning. The implementation by Firas Kaddachi, adapted to Singapore environment, links each beacon identifier to specific POI which, in turn is associated with an activity.

Mobility recommendation, one of the contributions of this thesis, introduces new concepts and new ways of evaluation. More expressivity of the language construct has been used to make compact rules. Evaluation of the current situation provides a factor for each chosen aspect: daily fitness progress, air quality, weather forecast, disability, temperature. The product of the factors provides a resulting desirability for each mobility available solution.

Including mobility outdoors, and the possibility of including more activity resources prompted a reflection about being able to detect more than one activity at any moment. An example is "inVehicle" activity detected by the smartphone activity recognition system and imagined "reading news" detection that could be done by the smartphone as well. Adjustments in the reasoning were made in a development branch. More experimentation is required to include this feature in the main release of the platform.

Simulation

This ubiservice feature provides an interface to launch reasoning on injected data. Depicted in fig. 51, its use is to showcase the possibility of the reasoning to our industrial partner. The simulation allowed to inject certain knowledge elements into the knowledge base related to the user's space: quantity and quality of user's sleep and current weather. After injection, option Launch simulation triggers the notification on a phone for demonstration purposes. It is also possible to observe the changes in the knowledge base on the server-side with the option Reasoning cycle. In order to test a different configuration, option Remove simulation eradicates all triples that were introduced in the knowledge base for the purpose of this simulation. The user interface evokes three types of data intended to be considered in the reasoning process: user profile, user history, and real time data. Ideas demonstrated with this feature were later implemented and enhanced in the Moover application detailed in the following chapter. Even before the Moover application has been launched, there were works on partial tasks that were necessary to provide rich services. In particular, the activity recognition was considered a necessary feature. My colleagues, Pau Oliver and Joaquim Bellmunt worked together to make an activity recognition algorithm based on machine learning technologies. I performed the integration and presented the paper about our findings during iiWAS 2017 [Kodyš et al. 2017b]. This work was reevaluated and assessed for inclusion in the mobility solution application that was going to become the future Moover application.

Oliver chose the approach of gathering the data of all available sensors: smartphone, timestamp, latitude, longitude, speed, location elapsed time, gyroscope (3 directions), gyroscope uncalibrated (3 directions), gravity, accelerometer (3 axes), linear acceleration, magnetic field, magnetic field uncalibrated, rotation vector, and geomagnetic rotation vector. It created a high-dimensional data that was fed into the machine learning algorithms. Their relative performance was evaluated using 80 % of the data to train the technique and the remaining 20 % was used to assess the performance of such a data. A critical point of view of this method must mention that there was a high chance that the data was taken from the same batches as the training data and the risk of overfitting was too high. A plot of the data according to the two principal components is shown in fig. 52. The figure illustrates Figure 52: Data separation according to the first two principal components using data collected with ActiviTrack how spatially distributed in the two most differentiating dimensions the data is. We can observe that the separation is not obvious and other dimensions may or may not help to discern the data.

As part of my contribution to this branch of research activity, I integrated the software components in a simulation environment of UbiSmart that makes use of these algorithms and provides a simple feedback in form of events connected to given smartphone. However, despite the theoretical result, in practice, we learnt that the model of recurrent neural network was not able to predict in a more accurate way than a stock solution from Google that is provided as an API for every Android developer. Comparing the two ways, our results were not satisfying in power consumption and complexity.

For further implementations, we decided to choose the Google API. We decided to provide a possible fall-back to our previously developed solution in case of disruption of the service provided by a third party.

Introduction

This chapter offers an overview of the design and development process of the Moover mobile application for Android operating system. I will describe what work has been done to prepare the necessary components for this application, how the application has been created, followed by a description of the implemented functionalities. The results of the experimentation in real conditions when we handed the application to voluntaries are described in section 7.

In order to provide services ubiquitously for the future ageing population, we adapt to the younger generation who is still active. As we perceive the movement as the main positive factor in well-being, we made it the central theme of our approach. In collaboration with PSA Group, a mobile application has been conceived, developed and tested. Julien Raphel was responsible for the graphical design, using the tool Figma10 . Under my supervision, Adrià Gil Sorribes developed the application for Android operating system for mobile phones. I took over the application's development when Sorribes' work experience assignment was completed. My contributions include architectural and some of the features specified later. I designed the backend service and made decisions about the implementation of the reasoning underneath.

Active Mobility

Medical research offers numerous pointers towards the positive effect of physical activity and active mobility on our health.

As is emphasised in [START_REF] Nystoriak | [END_REF], "[i]t is widely accepted that regular physical activity is beneficial for cardiovascular health. Frequent exercise is associated with a decrease in cardiovascular mortality as well as the risk of developing a cardiovascular disease. Physically active individuals have lower blood pressure, higher insulin sensitivity, and a more favourable plasma lipoprotein profile." [Colberg et al. 2016] encourages "unstructured physical activity". It is explained as the errands, household tasks, dog walking, or gardening -in contrast to planned exercise.

Even in advanced age, it is not too late to start even a simple exercise such as walking to notice improvements [START_REF] Desouza | [END_REF]]. Light physical activities like a walk has been recommended to cope with type 2 diabetes [Duclos et al. 2013]. On one hand, some studies seem to show some mild additional positive effect of a walk after the meal in individuals with type 2 diabetes when coupled with a specific diet, [Francois et al. 2018, Myette-Côté et al. 2018].

[ Colberg et al. 2010] warns that "[a]lthough physical activity is a key element in the prevention and management of type 2 diabetes, many with this chronic disease do not become or remain regularly active". Furthermore, they elaborate: "Highquality studies establishing the importance of exercise and fitness in diabetes were lacking until recently, but it is now well established that participation in regular physical activity improves blood glucose control and can prevent or delay type 2 diabetes, along with positively affecting lipids, blood pressure, cardiovascular events, mortality, and quality of life."

As a reminder that the physical activity is not a solution for every problem, [Rees et al. 2019] points out that there is no long-lasting effect on glucose level of an afternoon walk before dinner. In spite of the cases described in this study, the scientific community agrees on a direct positive impact of physical activities on health and quality of life.

Within the scope of this work, we consider active mobility to be one or a combination of following activities: walking, jogging, cycling and to a certain extent, using a scooter or even taking public transportation, as there is an additional physical effort compared to use of a private car or motorcycle.

Getting physical exercise through active mobility is convenient. It has the potential to decrease the cost of commute if it can replace some parts of the journey. It can also save time that would be needed to get to an activity-specific environment like a gym. Although active mobility is essentially an outstanding way of improving one's health, the outdoor environment is an important risk factor. For instance, Physical Activity through Sustainable Transort Approaches (PASTA) project specifically identified11 air pollution, noise, and risk of accidents. Air pollution becomes dangerous due to increased respiration rate during a physical activity and for that reason, the authorities usually discourage people from performing them if the concentration of particles reaches defined thresholds.

Nevertheless, research evidences suggest that the benefits of physical activities such as walking and cycling outweigh the potential detrimental effects of air pollution exposure and the risk of traffic incidents [START_REF] Mueller | [END_REF]].

Our aim is to promote active mobility in order to make it more accessible and preferable to other kinds of transportation, such as personal vehicles, taxis, or other similar services. The focus is thus on enhancing and protecting the health of our users. This has to be done with respect to their profile and environmental impact of the chosen mobility solutions. Other useful indicators include the current daily progress, e.g. using step count, and other real-time and near real-time data.

We approach it by providing services made available by local companies and government and merging them in a simple interface. In the backend, we use semantic technology to facilitate the evolution of the application in order to integrate new features. We make it modular and allow administrators to create new content that can be directly visible to our participants.

Context in Singapore

In order to make an application for everyday assistance, we chose to settle it locally to Singapore context.

As in other cities, public transportation features the problem of the first and the last mile; the distance between the starting point of the commuter's journey and the most convenient transportation node (bus stop, interchange or MRT station), and similarly, the exit point of the network and their real destination. Multiple options are currently available. The most straightforward is a walk to rental devices or taxi services.

Singapore makes a continuous effort to build sheltered walkways, and expand the mass rapid transport (MRT) network, cycling paths, and park connectors. In 2017, Singapore made steps towards more sustainable transportation with Active Mobility Act.

At the same time, bike-sharing became a large scale issue as the competing companies figuratively flooded the city. The city-state allows riding bicycles both on walkways and roads (unlike, for example, France where riding a bike on a walkway is tolerated but not allowed). Incidents involving abuse of the rental bicycles soared and careless users often left the bicycles in public spaces like in the green areas.

The problem was acute to the extent of pushing the legislators to define and enforce parking restrictions for bicycles.

Additionally, the use of Personal Mobility Devices (PMDs) have sharply risen. As a safety measure, restrictions on maximum speed had to be reviewed. In the latest legislative intervention in effect from February 2019, the maximum riding speed on walkways is 10 km/h for all devices. Shared paths (bicycles, rollers, walking) and park connector network allow 25 km/h as summarised in fig. 53.

Figure 53: Speed limits for mobility devices in Singapore in effect since February 2019.

Research Problem

Our aim to use the technological means to improve the quality of life of any user. Our target group is the global population -all ages and conditions. Specifically the inspiration came from caring about common illnesses like type 2 diabetes or asthma where the increased exercise is usually indicated as a factor with positive influence [Duclos et al. 2013]. Active mobility is seen as one of the most affordable ways of getting some physical activity done.

The main interest of ours is to motivate the person while ensuring maximum convenience given the space we have. This means pushing our message without too much pressure in order to keep the user's attention and interest. From the layout point of view, all necessary information should be provided without overwhelming the user.

In the backend side of the application, which is my main contribution in this application, we ought to provide the aforementioned services in a dynamic way, which is transparent to the user and having a lot of flexibility as the parameters need to evolve over time. New sources can be added and discontinued sources must not affect the functionality of the technological solution. (For instance, the wind reporting was discontinued when the application was ruled out.) From a software engineering point of view, the proposed solution is expected to be modular.

Semantic web technologies provide interesting tools to create knowledge-based systems. They provide modularity and flexibility when removing or inserting the information. However, the main difficulty is that the logical inference may produce unexpected results and therefore, verification mechanisms have to be implemented.

Within the field of semantic technologies in mobile applications surveyed in [START_REF] Yus | [END_REF], we position our software as a client-server architecture where the reasoning is performed in a remote server. In this setting, the client only formats and displays the information. The application would belong to several categories: health, recommendation, and map-based.

In related work, an architecture of a Mobility Recommender System was proposed in [Di Martino & Rossi 2016]. Their architecture mostly on the vehicle transportation optimisation and last mile. They haven't published any implementation of their architecture.

In the recent study [START_REF] Bernardo | [END_REF]] about the smart mobility in Lisbon, Portugal, the authors review several mobile applications. Although these applications provide inter-modal and multi-modal functionalities, environmental factors and personalisation are completely missing. Their focus is mainly on journey planning, integrating resources for traffic alerts or other journey related resources.

To our best knowledge, no application combining a mobility solution choice with environmental and personal information was available at the time of developing Moover. We believe a way of merging the heterogeneous data is a valuable contribution to possible uses of the semantic web technologies.

Choice of Technology

Generally speaking, measuring devices can be placed in the environment and on people. In practice, the options are driven and restricted by the technology and the legislation. The technological limits are set by available components and the required features. The legislation requires respect of regulations and ethical approvals in particular. For our application, we identified the key features to be unobtrusiveness, ease of use, availability, privacy, and low cost.

Because of privacy concerns, some methods were ruled out, such as camera systems with facial recognition.

An approach respecting the privacy consists in an installation of beacons. Similar to beacons for maritime navigation, a bluetooth beacon repeatedly emits a signal. This signal translates to a unique identifier of the beacon. In this way, any other bluetooth-enabled device can detect and identify the beacon. It is worth emphasising that, in principle, a beacon does not collect any information and only provides it to other devices. In this way, it also transfers the responsibility of data collection to the receiver.

To choose the receiver, we considered several devices worn by a user. Their review can be found in section 2.2.8. A smartphone, a cellphone with computational power, seemed the right choice. Its advantages are its global acceptance, a well supported ecosystem for application development. Moreover, a special aspect is that the user is able to set their own level of privacy. Due to high and increasing proliferation of these devices among all populations, the "smartphone literacy" is increasing as well. In [START_REF] Ketelaar & Van Balen | [END_REF], authors collected questionnaires (N = 924) from Dutch smartphone owners and their findings "show that the more privacy concerns users have, the more negative their attitudes are towards the collection of location data by their smartphones, and that they adjust the settings of their devices accordingly". As a consequence for application development and deployment, it is important to clearly inform the user about the data collection.

The selection of the development platform was subject to a discussion. Although, covering the full range of platforms and smartphones is increasingly possible with cross-platform development tools (e.g. Xamarin, orApache Cordova which powers Phonegap and Ionic frameworks). We weighted their disadvantages and available human resources. The main disadvantage is lack of platform-specific features (for instance activity recognition available in Android). As this work was to be carried out by Adrià Sorribes and myself, we decided to focus on the most popular smartphone platform which corresponded to the work experience focus of Sorribes. According to data collected by StatCounter web analytics service via a tracking code on "more than 2 million sites globally"12 , 75% of smartphones use Android worldwide, in Singapore 13 , the reported number dropped to 50% from 87% in 2018, see fig.

Towards Moover

Before entering the development of the Moover mobile application, several applications had been developed within IPAL laboratory.

In 2017, a mobile application named ActiviTrack was started by Pau Oliver under the supervision of Joaquim Bellmunt. Its purpose was to collect labelled data about mobility for machine learning to perform an automated activity recognition, its development is discussed in section 4.6.6.

When starting a mobility of a different type (driving a car, walking, running, riding a bike, nothing), the volunteer chose the activity type. Labelled data and the machine learning application was published in [Kodyš et al. 2017b].

Name of ActiviGate contracts the names of two other applications: ActiviTrack and UbiGate, one standing for activity tracking, the other for UbiSmart gateway.

Although the original intention was to reuse the algorithms from ActiviTrack, Sorribes' work showed that the previous results were in real deployments outperformed by Google's activity detection.

The first stage, "ActiviGate" did not expect any user interaction in its first version. It automatically and periodically reported user activity based on sensor readings from the smartphone where it is installed. Once the activity detected, the smartphone's current connectivity is used to relay the activity information to our servers. In its enhanced version, the information from a fitness tracker (Fitbit) was integrated by Sorribes. The information was made available to the user as well as to our servers.

Reaching the second stage, it became a collaborative work, the application was named "Moover". The collaboration included our colleagues from PSA Group, most importantly, Julien Raphel for User eXperience (UX) design. In this stage, I contributed with back!end services that provide a rule-based reasoning via UbiSmart platform.

The purpose of the application was to offer a service of mobility recommendation given a complex environmental and personal information. In consideration were to be taken weather, air quality and also the user's recent activity (past day and week), personal goals and particular personal long-term or short-term conditions (asthma, disability, ...) .

Details about the early versions of ActiviGate will be given in the following section.

ActiviGate Version 1

ActiviGate is the first stage of Moover application. Its main goal is to monitor the subject's activity in a non-invasive way, using the data produced by the owner's smartphone's sensors. A basic smartphone generally provides readings of following sensors:

• Accelerometer: Measures device's acceleration in 3 perpendicular axes.

• Gyroscope: Detects the current orientation of the device, changes in the orientation.

• Magnetometer: Measures the strength of the magnetic field.

Some work has been already done in this field trying to detect the type of mobility developing complex machine learning algorithms such as in [START_REF] Vavoulas | [END_REF] in which they use the MobiAct public dataset to extract useful features and then use them with different classifiers to compare the system performance. There is also some work done with a deep learning approach such as in [Yao et al. 2017] and [Ronao & Cho 2016]. A replication of their results is not possible from the information provided these papers. Sorribes made an effort to train his own algorithm applied on available public datasets with sensors data. However, the task would have required more time than was available. Instead of implementing our own system we chose to use a public API developed by Google, which automatically detects activities by periodically reading short bursts of sensor data and processing them14 . As is shown in fig. 55, this Google API provides an easy and reliable way to detect the type of mobility. A confidence score between 0 and 100 is also provided. Following activities are reported:

• Still

• Walking (or "on foot")

• Running

• On a bicycle

• Tilting

• Unknown

• In a vehicle

In the event track of fig. 55 we could even discern the lift and escalator rides during the walk to the platform segment, if we are familiar with the environment. Similarly, we could determine the number of MRT (train) stations on the way home. fig. 55, we can observe a lower quality data for the same journey: after exiting the office, a walk towards the underground subway (MRT) is detected, followed by 30 minutes of MRT ride, and by ten minutes walk to get home. A particular activity "tilting" is observed. It means that the device's angle significantly changed. It may be interpreted as flipping the phone in the hand or shoving it into a backpack.

ActiviGate Version 2

Integration of a fitness tracker "Fitbit Charge 2" marked the second version of the ActiviGate application. Using Fitbit API makes it easy to support any device because the data is linked to the user's account and the device itself is irrelevant. The main advantage is that this provider of IoT wearable devices allow us to obtain the following information:

• Activity and Exercise Logs Fitbit provides an API for accessing the data. Its integration comprised of two main connections: to ActiviGate and to UbiSmart. Sorribes added the registeration of a Fitbit device within the ActiviGate application to be able to retrieve the data coming from the device. For UbiSmart, a service that retrieves the data from the API stores it in the database was created. This data was stored in the same database as other UbiSmart components'. It allowed the access it from UbiSmart web interface and the development of new views and analyses. Sorribes then modified the user interface of ActiviGate to show the data in a straightforward way (third screen in fig. 61).

Authenticated Access

In order to authenticate the requests for information, Fitbit uses protocol OAuth 2.0. An Access Token is provided when the Fitbit user authorises our application to access their data. Then, the Access Token is included in the header when making any HTTP request to the Fitbit API. In our case, we selected the Client option since we will be using the Implicit Grant Flow which has the following steps:

1. The application redirects the user to Fitbit's authorisation page shown in fig. 58.

2. Upon user consent, Fitbit redirects the user back to your application's redirect URL with an access token as a URL fragment.

3. The application stores the access token client side. It will use the access token to make further requests to the Fitbit API. { "activities": [ { "activityId": 90013, "activityParentId": 90013, "activityParentName": "Walk", "calories": 153, "description": "Walking less than 2 mph, strolling very slowly", "duration": 1485000, "hasStartTime": true, "isFavorite": false, "lastModified": "2020-04-01T13:41:43.000Z", "logId": 30043639953, "name": "Walk", "startDate": "2020-04-01", "startTime": "21:05", "steps": 2335 }, { "activityId": 90009, "activityParentId": 90009, "activityParentName": "Run", "calories": 2389, "description": "Running -5 mph (12 min/mile)", "distance": 0.5378, "duration": 678205000, "hasStartTime": true, "isFavorite": false, "lastModified": "2020-04-09T10:01:53.000Z", "logId": 30024011304, "name": "Run", "startDate": "2020-04-01", "startTime": "21:35", "steps": 541 } ], "goals": { "activeMinutes": 30, "caloriesOut": 2471, "distance": 8.05, "floors": 10, "steps": 10000 }, "summary": { "activeScore": -1, "activityCalories": 1042, "caloriesBMR": 1556, "caloriesOut": 2469, "distances": [ {"activity": "Run", "distance": 0.5378}, {"activity": "total", "distance": 8.41}, {"activity": "tracker", "distance": 8.41}, {"activity": "loggedActivities", "distance": 0.5378}, {"activity": "veryActive", "distance": 3.92}, {"activity": "moderatelyActive", "distance": 1.69}, {"activity": "lightlyActive", "distance": 2.79}, {"activity": "sedentaryActive", "distance": 0} ], "elevation": 39.62, "fairlyActiveMinutes": 28, "floors": 13, "heartRateZones": [ { "caloriesOut": 1823.33568, "max": 94, "min": 30, "minutes": 1293, "name": "Out of Range" }, { "caloriesOut": 499.73064, "max": 131, "min": 94, "minutes": 104, "name": "Fat Burn" }, { "caloriesOut": 82.81992, "max": 159, "min": 131, "minutes": 9, "name": "Cardio" }, { "caloriesOut": 21.40776, "max": 220, "min": 159, "minutes": 2, "name": "Peak" } ], "lightlyActiveMinutes": 171, "marginalCalories": 594, "restingHeartRate": 67, "sedentaryMinutes": 816, "steps": 10669, "veryActiveMinutes": 39 } }

Figure 60: Example Response

Figure 61 shows the main screens of the second version of the ActiviGate Android application. In this case to stop the activity recognition, the user needs to go to the top right-side menu and choose the option to stop activity recognition. Otherwise, it will run even when the application is closed.

The workflow follows fig. 62 schematic in which we see that in a parallel way, the application and the UbiSmart server retrieve data from the Fitbit Web API. There is a communication between ActiviGate and UbiSmart to exchange the access token needed to perform the authentication.

Design Process

The design process can be summarised in the following way: first, we defined the main characteristics of the application, followed by the user interface design driven by functionalities. As soon as the basic expected visual communication was defined, the work on the backend started with the definition of expected outcomes and the algorithms could be designed. The process reiterated several times to add specific features in order to obtain a fully functional Android application.

Figure 63: On a request from the application, platform UbiSmart (designed according to [Tiberghien 2013]) injects available information from multiple sources into the semantic structure of the knowledge base, applies rules and serves a comprehensive decision and its context.

The system produced by this process is depicted in fig. 63. Upon opening, our Android application sends a geo-located request to our server. The server interacts with necessary APIs to obtain the data: the current physical activity progress rate from the fitness tracker, e.g. 90 %; the weather 2 h forecast, e.g. rain,and current temperature, e.g. 26 • C; and the current air quality index (AQI), e.g. 140. From the profile stored in the database, the information about personal condition is retrieved: asthma, e.g no; disability, e.g. yes. All this information is injected into a semantic graph structure using an ontology model in which the parameters fit: the knowledge base. The reasoning process applies our set of rules on this knowledge base.

The rules keep producing new knowledge until a "desirability" of modelled mobility solutions is obtained. This information is returned to the client and along with environmental factors (forecast, temperature, AQI). The mobile application then presents this information to the user using colour codes for each mobility solution.

User Interface

This part of the design process was performed by our industrial partner having a user-centred approach in mind. The design process is known as "Double diamond" [Design Council 2019]. Contains 4 stages: discover, define, develop, and deliver.

From gathering of the inspiration and brainstorming workshop, we defined main features of the future application. After its validation, the development began.

The application hand-over to end-users represents the delivery part. However, the development and user feedback is continuous.

The design of the system started with an overview of applications currently offered for major operating systems in sections concerning mobility, well-being, and physical activity. Their interfaces were analysed and they were used as examples of interface complexity in order to choose the adapted complexity level for our end user. Opinions of potential users and other stakeholders were collected in a workshop setting, using questionnaires and brainstorming techniques.

The outcome showed that a most adapted application would have a very simple interface so that it could be used without a lot of interaction, with few indicators. Then, incrementally complex view was defined for each indicator and service integrated onto the application (Fitbit integration, API for bus arrivals, points of interest, bike-sharing integration).

In this phase, we defined the positioning of our application as mobility choice using simple indications for each considered mobility. Simple indication of environmental factors was also presented in the main view. The main use case of the application was to let the user decide which mobility solution to choose according to the current fulfilling of their goals (step count) and current air quality and oncoming weather conditions. The system was designed to allow the integration of indoor (sensors at home) and outdoor monitoring (beacons detecting the user presence).

We defined the simple interface as a three level indicator according to a colour level: green, yellow and red with the intuitive meaning of the traffic lights or gauges indicating a measure of danger.

Around this basic indicator, we developed an algorithm that aggregates available dimensions and projects them in a one dimensional variable "desirability", having value between 0 and 1, for each of the selected mobility solutions. It represents to what extent we recommend the given mobility solution provided the available information. The interval was divided into three segments, one for each colour.

[0, 1/3]: red -mobility solution is discouraged given the circumstances;

(1/3, 2/3]: yellow -not recommended;

(2/3, 1]: green -recommended. This application's target group is user base of all ages from 20 to 70 years. Having an improvement of users' well-being by enhancing their mobility. It means that the application's aim is to influence the decisions about the type of mobility when making a journey. All depending on parameters, such as weather, air quality, or the activity already carried out during the day.

It was build upon the second version of ActiviGate, with more improvements: an added Markov smoother on top of the Google API to boost its accuracy and a notification service for UbiSmart that allows the server to be notified whenever a user has synchronised its device with the Fitbit app to keep the database updated with the most recent data. More details will be given in the following sections.

Improving Google API

In order to improve the activity recognition provided by the Google API, we followed the study performed in [START_REF] Zhong | [END_REF]. The paper studies different classes of detected activity. It explains that the 2014 update of the API separated the activity "on foot" into two subclasses: "walk" and "run".

Their proposed algorithm named ARshell+ significantly improved the accuracy in most of the activities tested in practice in 3 different devices. The proposed solutions were released as open-source projects. After the integration of the code into our Android application, we could confirm that the accuracy improved.

A further improvement was carried out by Sorribes. Our experimentations showed that the "still" activity was detected during MRT (train) transit time. Following strategy was implemented as a correction measure. When the user is detected "in vehicle", the activity will be detected until the activity is different from "in vehicle" or "still".

Similarly, the transition from "walk" to "still" was suppressed unless the "still" activity was detected at least for 5 minutes of duration. Making these amendments helps to define the semantics of the detected activities. This information can be further codified and used in the reasoning part. Although it has not been implemented yet, it creates new opportunities of expansion of our ontology.

Fitbit Notification Service

The current Fitbit bracelets use Bluetooth and Internet connection enabled devices to report the user's activity. It can be noted that the application can be run not only on a smartphone but also on a personal computer with Bluetooth and Internet connectivity. For elderly people without a personal computer or a smartphone, the software could be installed on a Raspberry Pi gateway. This gateway could be installed in a commonly accessed space, such as a community centre.

Default settings of the companion application make the device upload the data any time it gets within the range. It can be continuous upload, every hour, or a after a long delay. For example after returning from a week-long vacation, all the data is uploaded at once. To ensure the best service, Fitbit provides a subscription API that allows developers to be notified about the new data. Whenever the user data changes, a specified URL receives a notification about this update. Subsequently, the developer can fetch the new information. This is a pragmatic approach because potential polling implementations would overload Fitbit servers. This process is illustrated in fig. 64. The system requires the developer to have their callback URL available -in our case it is an endpoint in UbiSmart platform. The endpoint is supposed to accept a HTTP POST request made from Fitbit servers. It contains meta-information about the data modification in a JSON format. It is worth emphasising that this notification does not contain the updated data. The developer has the responsibility and freedom to take an action to fetch the actual modified data of interest. The number of calls for data fetching from Fitbit servers is limited. Therefore some simple strategies to avoid exhausting the quota might be implemented. We implemented a limit-and-wait strategy. We use a counter of notifications and when the limit is reached, the notifications get ignored until the counter is reset. In this way, we keep the user data up to date on server side.

Application Walk-through

This section explains the functionality of the application through the sequence of screens. When launched, the application displays an introduction information about the collaborative work of PSA and IPAL (fig. 65 a). Then, a login screen (fig. 65 b) requires user-name and password to access any other features. The "Terms and Conditions" screen will greet the user after the first successful login. User is expected to read carefully the text however a verbal communication is recommended during the deployment. Agreement to these terms with "accept" button gives the user an access to the content of the application. First, an activation of the Moover profile is offered that invites the user to fill their profile in. The form asks for a name (or nickname), age, height and weight. In this screen, particular situation can be specified in "healt problems" section. The latter allows us to adapt the recommendations. The registration of the Fitbit device with the application is also offered as a check-box option. Below the profile, personal goals can be set.

Colouring of the value indicates whether the goal is weak (red), medium (orange)

or strong (green). These daily goals are expressed as amounts of steps, kilometres and calories.

The user is expected to allow the use of Google location services in order to proceed.

The main screen of the application is presented to the user. It consists of a map view centred on the user's current location as detected by the location services. On top of the map, a user icon is surrounded by a circular progress indicator. It displays the current "Moover progress". A measure indicating how well the user is doing with respect to their goals. The ring is complete when the daily goals are reached. On the left side of the avatar, there is a refresh button. On the right side, three icons indicate respectively current weather condition, temperature and air quality. This information is retrieved in real time through UbiSmart platform from the National Environment Agency from Singapore, using the user's current location.

A roll-up menu is available from the bottom-left corner of the screen. It contains in this order following functionalities: points of interests settings, Google Maps search, profile settings, functionalities overview screen, hide the menu.

In addition, there are seven icons corresponding to the seven mobility solutions that the application offers. Every mobility solution is actionable. Tapping it, the screen changes and displays some information relevant to the chosen mobility solution.

Geographically located information shows in the map and details in the lower half of the screen that can be dismissed.

The buttons and provided functionality are as follows:

• Walk -the covered walkways and hawker centres appear in the map

• Bicycle -rental vehicle positions and for personal bicycles bicycle racks are shown in the map, lower half of the screen contains a link to the respective service provider's application

• Scooter -the map will show the positions of rental points

• Motorbike -only a notification about unavailability of this service is shown

• Car -taxi cars locations and current traffic situation appear on the map, lower part of the screen offers a link to an application providing the taxi service

• MRT (train) -train stations and exits are displayed on the map • Bus -bus stops are displayed on the map and lower half gives the information about next bus on the selected bus stop Elements shown on the map are active and when selected (touched), lower part of the screen offers navigation to them via the Google Maps application. As mentioned in section 5.7.1, the influence of the user happens through colourcoding. Green for highly recommended mobility mode, yellow for those that are not recommended and red for those that should be discouraged given the available information. On every launch of the Moover application, the server side undergoes the reasoning process. The result is then returned to the client application.

Since the final destination of the user's journey is not known, the most adapted choice is to be made by the user. Our assessment gives an overview of how suitable each mobility is to the current situation.

The current situation covers the progress in goals of the user. It signifies that when the user has done very little physical activity during the day, passive mobilities' score will be negatively affected.

Another situation can be illustrated by a following example. The user is asthmatic and the air quality is low. The application will not encourage to choose a bicycle since it is not recommended for people with respiratory problems to perform any outdoor physical activity when the air pollution is above a certain threshold.

If the user avatar is pressed, detailed information about the daily activity and a

Integration in UbiSmart

The integration within UbiSmart platform was added at the later stage of this application.

As it has been mentioned before, the user needs to enter their credentials for the login step in the application. The username and the password are hashed and sent over an HTTPS connection to the server. When the server receives them, it checks that they match its own records and, if so, it sends an OK message to the application with a token that will be used from now on when the application does a request to the server as an access token. This OK message is different depending on whether it is the first time the user opens the application. Otherwise, the OK message will contain the profile information that is already stored in the server database. That information is then stored within the application's shared preferences. Sending the profile information is useful when the user chooses to remove application data. In this case, the information is not required to be prompted again.

Once the user is authenticated, a request message is sent to UbiSmart. The server then performs several calls in order to get the information about the weather and the air quality. As soon as all these bits of information (including the fitness tracker and profile) are gathered, a reasoning is triggered. Its process is explained in the following section.

As soon as the result with the recommendation is obtained, it is transferred to the application along with the environmental data. As a JSON formatted message it has the following content: Whenever the profile information changes, the application will make the same request to the server. The updated recommendations will be delivered for all seven mobility modes.

The information stored in the profile and the recorded activities are available for viewing in the web interface of UbiSmart. The overall integration with UbiSmart can be understood in the schematic shown in fig. 68.

The life cycle of the application is monitored in a very simple way. When the application is started or re-entered, or when the application is left, a record is created and stored in the application memory until it can be sent over to our server. This information can be used for further analysis for a better understanding of the user's behaviour.

Reasoning

The core of the application was the engine for decision process about each mobility solution. Our reasoning processes has already been deployed in indoor and outdoor environments centred around elderly people. The elderly people were monitored for the increase of their autonomy while letting their caregiver see that the activities are expected ones. For this application, we used the same platform so that it is possible to integrate both systems for the same user. In such way, we would be able to offer For a reference, we provide only a short technological description, details on the used technologies can be found in [Tiberghien 2013]. In very simple terms, we make use of semantic web technologies to model the user and their environment. The expression language is N3, Notation3 which is a dialect of Turtle language, a terse expression equivalent to RDF, itself a subclass of XML. The language describes information organised in triples of concepts: subject, predicate, object. A set of the triples forms a knowledge base.

Model

The main component of semantic web technologies is the knowledge base (KB) that contains all pieces of information. This information is structured in triples. A triple has a form of a three-term sentence, e.g. "hom:aqi qol:hasValue 105". Each term is either a concept or a literal. Each concept is identified by a unique identifier -URI that points to its definition. A literal is a value of one of usual data types: string of characters, numerical value, boolean value, ... The dictionary of the terms and a "grammar" are defined in an ontology. An ontology describes what can exist in the world described by our knowledge base. In simple words, it defines the hierarchy of concepts. For instance, "cycling" is a "mobility solution", which translates to concept of "cycling" being a subclass of the concept of "mobility solution".

Rules

Rules define the mechanics of our world and are also expressed as a special kind of triples -subject is a formula, i.e. zero or more triples, enclosed in curly braces, predicate is the string "=>", object is another formula written in curly braces. Formulas can contain special terms beginning with a question mark, e.g. "?weather". They are similar to variables in imperative programming languages. Their scope is limited to the rule.

A set of rules applied on the current knowledge generates new information. Depending on the evaluation of the output, appearance of some specific triples may trigger actions on the outside world (notification), removal of the information from the KB. Rules can be used to perform arithmetic operations, aggregation or simple inference "if ..., then ...".

The following Source 7 is an excerpt of the rule set used in our application to determine the coefficient of air pollution from the measure of AQI obtained from a public source. []e:findall((){hom:johndoe qol:hasMedicalCondition qol:asthma}()).

(hom:walk hom:bike hom:scooter hom:moto hom:mrt hom:bus hom:car) list:member ?mode} => {?mode hom:aqiFactor 0.8}.

{hom:aqi qol:hasValue ?v. ?v math:lessThan 150. ?v math:notLessThan 100.

hom:johndoe qol:hasMedicalCondition qol:asthma.

(hom:scooter hom:moto) list:member ?mode} => {?mode hom:aqiFactor 0.6}.

Reasoner

Once the description of our universe (knowledge base) and its laws (rules) is ready, we apply a reasoner. A reasoner is an application that takes our triplets in input, along with the rules to be applied and a query that defines a selection of the knowledge base that is of interest for us. The reasoner we use is called "eye" shorthand for "Euler yet another proof Engine". The choice of this tool is discussed in [Tiberghien 2013]. Eye is accessed via a Javascript interface inside our NodeJS application. Components of our application can add, remove, and update the knowledge base.

Implementation of a Decision Table

For this application, we defined basic statements and implemented the rules. However, the most useful was the enumeration of all possible states in a table. It is automatically generated from a list of conditions for each dimension and their combinations. It was very helpful during verification process. The table includes all the obvious combinations and main weather conditions: if the weather forecast is hostile, the active mobility will not be recommended. It includes higher values of air pollution, probability of rain or storm, and strong wind.

The weather is categorised as one of these categories: fine, windy, rain, dangerous, or unknown. Each of them attributes different modification to the weather coefficient of a specific mobility solution. Each of these conditions is projected into a scalar value with target range of 0 to 1.

For each level of air quality indicator specific conditions were added for asthmatic users.

Similarly, a score for currently achieved goals computed as a scalar value -0 means no progress, 1 means 100 % of goals, this value can be greater than one but for the computation, it is capped at 1. Specific sample cases were decided for health conditions: disability (e.g. on a wheelchair or broken leg) and the asthma (heavier impact of air pollution on recommendations).

For the proof of our concept, the we integrated 6 dimensions with the segmentation as follows. The full table contain 5 weather conditions × 2 temperature cases × 4 AQI intervals × 1 scalar goal measure × 2 disability × 2 asthma = 160 cells (each having a value for every mobility solution).

The visualisation of this space is presented in fig. of digits that denote conditions in order weather (1-5: unknown, rain, fair, danger, wind), AQI (1-4: from better to worse), asthma (0 no or 1 yes), disability (0 no or 1 yes), temperature (0: under 36°C or 1: over 36°C).

There are 8 coloured segments, each of them represents a specific configuration of the aforementioned binary parameters. They are coded in RGB 3-dimensional colour space with following attributions: temperature = red, asthma = green, disability = blue. Their combinations give a colour combination: e.g. black (grey background) is at all values are 0, cyan has blue and green component so it depicts disability and asthma.

Within the coloured cluster, horizontal position indicates 4 cases of air quality indicator AQI with healthiest lowest values on the left and in this order: under 50, up to 100, up to 150, over 150. Vertical position within each coloured block are 5 cases of weather condition in this order: unknown, rain, good weather (fair, overcast, cloudy), dangerous (heavy rain, thunderstorm), windy. The indicated values are the maximum score the mobility can obtain in the configuration and passive mobilities are weighted with current progress in goals. Meaning that "car" will be "red" if there was no physical activity progress in the day, even if in the cell it appears green.

In case of non-use of the fitness tracker, we decided to show the results as if the daily goal was achieved (we show the colour as in this table ).

The current progress is adapted to the time of the day -100% score is obtained if at 50 % of the day, the user completed 50 % of their goal.

The importance of explicitly drawing this table is for validation of the approaches to make sure that all cases are covered with values that make sense. We made use of it during the verification process and it helped to discover issues with the model.

Product of all values is the measure of desirability of given mobility solution for the currently known situation.

Mobile Deployment

The application was distributed to participants along with an optional Fitbit device. We were interested in the usage rate of the application and feedback from the users.

In order to motivate the user feedback, the participants were invited to a lucky draw (fig. 71) where two participants would win an upgrade of their Fitbit device to a newer model. In order to deploy within the neighbourhood, an active collaboration with the Singapore Housing and Development Board (HDB) has been established. The HDB is the national agency which is responsible for the accommodation of more than 80% of the population and responsible for the neighbourhood urban planning.

The real-life applications of the project has been conducted with the help of two local Senior Activity Centre (SAC) organisations (TOUCH and AMKFSC), organisations appointed by the Ministry of Social and Family Development. Both SACs are dropin centres for the elderly, organize activities and provide a receptive and familiar environment as well as support services.

Projects

• stakeholder engagement in order to be driven by relevant user needs to ensure end-user acceptance.

H2020 PULSE: Participatory Urban Living for Sustainable Environments

PULSE is a H2020 European project under Grant agreement ID: 727816 funded on Research and Innovation action (RIA) scheme. The project started early November 2016 and will be continuing until the end of 2019.

PULSE (Participatory Urban Living for Sustainable Environments) will leverage diverse data sources and big data analysis to transform public health from a reactive to a predictive system, and from a system focused on surveillance to an inclusive and collaborative system supporting health equity. Working within five global cities, PULSE will harvest open city data, and data from health systems, urban and remote sensors, personal devices and social media to enable evidence-driven and timely management of public health events and processes. The clinical focus of the project will be respiratory diseases (asthma) and metabolic diseases (Type 2 Diabetes) in adult populations. The project will develop risk stratification models based on modifiable and non-modifiable risk factors in each urban location, taking account of biological, behavioural, social and environmental risk factors. Following the recommendations of WHO Europe (2015), the project will also focus on the development of metrics, and data-driven approaches, to community resilience and well-being in cities.

Deploying a Health in All Policies (HiAP) perspective, and a 'whole-of-city' model, the project will integrate and analyse data from the health, environment, planning, and transport sectors in each city. PULSE will pioneer the development and testing of dynamic spatio-temporal health impact assessments using geolocated populationbased data. PULSE will also develop simulation models of potential policy scenarios to allow decision-makers, citizens and businesses to ascertain the impact of proposed policies. The project will culminate in the establishment of Public Health Observatories in each urban location. These observatories will serve as linked hubs that utilise knowledge-driven processes and big data to shape inter-sectoral public policy and service provision, support citizen health, and encourage entrepreneurship in the fields of data science and mobile health.

PSA: Mobility & Well-being in the Urban Environment

The mobility dimension, active and passive indoor and outdoor, has a considerable contribution to the quality of life of people, particularly those with chronic disease, especially while considering the connected car as a logical extension of the connected home. This project aims to provide a number of innovative services to assist people in their daily life based on different means for mobility (pedestrians, public transport, car/taxi, MRT, etc.). KTPH also provides a wide range of outpatient specialist services.

Health behaviour and sleep monitoring importance Quality of sleep is a major concern for one's health, having an impact on a person's mental health, physiological well-being, and quality of life. Sleep disordered breathing, sleep apnea for instance, can result in serious health issues such as hypertension and stroke. Thus, it appears that monitoring the elderly's sleep is important for improving their health. At the same time, non-intrusive methods are preferred because they are easier to use for an individual.

From the simple fibre-optics mat, using the signal raw data, the processing algorithms are able to extract 4 main components of the overall sleep quality: heart rate (speed of the heartbeat), respiratory rate (contractions of the chest), body movement and sleep cycles. All those data are integrated in the platform.

Going further, the project has generated a compelling demand on the unobtrusive environment system. While using mainly industrial sensors, it has been providing useful information and resources for the caregivers to provide accurate services to the elderly care-recipients. The sleep monitoring solution (jointly developed internally) had a particular impact on both sides and is still under continuous improvement. On-going and future deployments have been conducted with other partners (such as local hospitals and medical facilities) in order to prove its clinical capabilities. Moreover, the overall solution is ready to be used in "Hospital without a wall" projects where patients can be transferred from the hospitals to their home under a continuous monitoring from the specialists.

A special component of the Singapore pilot has been the fibre-optics sleep mat. The mat enables the monitoring of vital signs such as respiratory rate, heart rate and body movement. It is used to monitor the elderly person's overall sleep quality in their homes and a co-study with the KTPH is being started in clinical conditions (sleep rooms in the hospital for elderly patients who have been through surgery or medical interventions).

France

Montpellier Pilot site focuses on preventing frailty through daily activities monitoring at home and in the city. The Singapore pilot site team have performed interview sessions with elderly participants in order to assess the system's overall acceptance and quality of the intervention. Those interviews have been conducted in different steps during and after the data collection iteration. During the iteration (both data collection and intervention services), interview sessions have mainly focused on the elderly person's Quality of Life, technology evaluation, and quality of service including intervention. Elders have integrated the unobtrusive deployed system into their daily activities and it is now seamless for them as they got used to have sensors inside the homes. Most of the elderly participants do not actually see the link between their activities and the visits or contacts with the caregivers but understand that some actions can be initialised from the monitoring system.

Before all deployments, and in order to ensure that the proposed solution/ service that the team deploys is adequate, in depth interviews were conducted to probe deeper into the elderly attitudes and motivations. Questions on topics such as lifestyles, health, Activities of Daily Living, mobility and the use of assistive technologies were asked so that their perspectives, decision pathways and concerns could be understood.

The team performing the surveys used a friendly and interactive approach to score each QoL dimensions following a list of questions and direct discussions with the participant. The approach is to ask open questions and engage the dialogue with the participant in order to fully understand the different inputs and concerns to establish a comprehensive scoring method.

Data Collection

A deployment is a process of setting a formerly designed system into real conditions. We identified following phases of the process: preparation, installation, functioning, removal, and closure. We split them in more detailed parts on which we will focus: administrative preparation, technical preparation, installation, monitoring & analysis, maintenance, removal of devices, debriefing with participants, and inspection of devices.

The process starts with administrative and procedural preparation, defining collaborations and finding participants. Even though this phase of the process is outside of the scope of this paper, some problems can be resolved before they happen. For example, this phase allows us to define intervention protocols, so that we can avoid improvisation. A parallel phase is technical preparation for the installation part.

In this phase, we must make sure that all necessary devices are ready and tested.

As well the exercise of installing the whole system should be tested and contain an estimate of the duration. The overall elderly people monitoring summary of collected events is presented in fig. 74.

Lessons Learnt

Installation phase in participants' homes is short and stressful, and it should be well-prepared and require operative resolution of problems (e.g. changes in order of visits, missing infrastructure, etc.) The visit must end with thorough tests of every component. A checklist is highly recommended.

The functioning phase contains the most unpredictable parts of the deployment. Most importantly, data collection within monitoring & analysis will yield to first overview of further problems (e.g. network connection differences). In parallel, maintenance is needed: periodical (e.g. topping up data plans for communication devices) and incidental. As incidents will happen, depending on failing component, a measure is to be planned. The intervention ranges from remote parameters adjustment to on-field intervention.

When the experimentation expires, the devices are removed and marked as returned.

The main problem might be possible damage to participant's environment during device removal (e.g. tape removal from the plaster).

Indoors It is crucial to respect basic instructions for pasting stickers: the receiving surface must be clean and smooth, and the sensor must be hold in place for at least 30 seconds. As of our experience, non-greasy wall can successfully hold a sensor. In Singapore conditions where daily typically ranges between 26 and 33°C, the surfaces can often be overheated (refrigerator without space around it to ensure proper cooling), greasy (kitchen tiles). We have tried hook-and-loop fastener ("Velcro") stickers and dimensional double sided tape ("3M"). We obtained a more stable positioning using double sided tape.

Various environments for sleep mat placement are illustrated in fig. 75. Some participants, instead of mattress, prefer sleeping on the floor on a wooden mat, fig. 75(b).

Outdoors We deployed Bluetooth beacons in public spaces. We opted for surfaces that are not exposed to rain or wind -they are basically under a roof or shelter. The device always lies down on flat horizontal surface or vertically on a clean ceramic tile.

Sensors

The main issue with sensors is that they fall off or run out of power. The fall can damage the sensor and render it unusable. This impacts the quality of data or stops sending data (e.g. contact sensor on the door). In several cases, the entrance doors' contact sensor disappeared, probably because of corridor sweeping. In one case, the sensor was painted over with the rest of the gate.

An expected problem is running out of power (on batteries). A maintenance should be scheduled. The lifetime of a battery can be best estimated while deploying a test deployment for a long period of time. It is worth making sure that the sensor configuration is well confirmed. For instance, a sensor sending the data every 10 seconds instead every 4 minutes makes the battery drain 24 times quicker. This will be discussed in Section 6.5.1. The battery discharge signalling pattern can be observed in fig. 76.

In some cases, we observed that sensors were sending only one type of events (e.g. "off" signalling absence and never presence) -in this case the problem was of software nature.

Remote connection

Operational problem solving was enabled by a remote connection to our gateways using secure shell connection where the gateways maintained a SSH tunnel to our server. In this way, we were able to gather information about multiple parameters (CPU temperature and load, RAM, storage).

Environment

The places where the devices are to be installed are often difficult to access (possibly with accumulated dirt), necessitating physical effort and gloves for protection.

Notably, sensors have to be fixed to their support or to a vertical flat surface. The choice of the place has to take into account the optimal position for tracking, and also the position where the sensor is not easily tackled (salient or near in the way for the residents). The placement of the sensor should take into account the possibility of its fall. Thus avoiding too high (e.g. ceiling), or over a sink or a toilet. Even if the optimal solution is to use screws, in many cases, it is not possible to drill holes in walls and the only option is to use adhesive materials to keep sensors in place. There is also a need to ensure that the washable surface is clean, by removing greasiness and dirt using a damp cloth with dish washing liquid, or wet and dry wipes.

Services and Solution Deployment

Providing assistive tools The technology deployed in Singapore is an unobtrusive monitoring system. Indoor and outdoor sensors collect signal information from participants and provide metrics on ADLs, mobility and lifestyle. The system presents the gathered information to authorised users, and, most importantly, caregivers of elderly people. The raw data is enhanced by being processed by the reasoning engine. Obtained through the logical entailment, the new information is presented as a set of visualisations. The main goal of the visualisations is to asses and enhance the QoL and well-being. A set of tools and services was co-created with the caregivers in order to enable a proper intervention (based on behaviour change tracking, activity recognition system, vital sign monitoring and ADL metrics). Visualisation However, as the sensors need to be unobtrusive and not to infer with the daily activities of the elderly, it is important to drive user involvement in the project in enabling the visualisation or use of the generated data. The system is usually considered working when the users can have access to a tangible set of visualisation tools and data representations. This is the main driver for user involvement, giving back the data and building frontend services together with the end-users empowers them towards their lifestyle and help to get better insights into their overall experience, shown in fig. 77.

A different set of frontend visualisations (fig. 78), accessible to the users have been tested, from simple data signals visualisations to computed data metrics and even innovative dashboards aggregating open data and external data such as air quality data or environmental data.

Technology Validation and Data Results

Data collection and interpretation

One item that is of some importance in the overall health is the sleep quality. As an example, the technical team performed cross checking between the different technology capabilities deployed and above-mentioned inputs (surveys). The sleep fiber optics sensors are able to detect body movement, heart rate, and respiratory rate. The output signal when the bed is empty is mainly noise (averaging around the same amplitude). The elderly sitting down on the bed or lying down will provoke a sudden peak on the signal detecting bed motion and then the system will zoom progressively into the body related amplitudes to detect the signal "respiratory patterns".

As the project is dealing with behaviour change, the data has to be consistent over time. Days or weeks are not enough data to go through the whole behaviour change process. For example, a decline in physical activity can be almost instantaneous for the case of an injury and is observed over days. However, a more global decline in performing the ADLs or at the socialisation level is more often characterised as a trend and result in a decline of several parameters over time.

An example of visual analysis of the data is shown in fig. 79.

Area of interest

As we deploy sleep mat for each house, one of the main area of study for this deployment is the assessment of sleep activity. Sleep disorders are fairly common in older adults. As one gets older, sleep patterns and habits change.

As a result, elderly people may have trouble falling asleep, sleeping fewer hours, or waking up frequently in the night or in early morning, and getting less quality sleep. This can lead to health concerns like increased risk for falling and daytime fatigue.

In fact, older adults need the same seven to nine hours of sleep that teenagers do.

Stability and scalability

The main challenges are from a technical and design point of view. The research team works closely with end-users (caregivers) to stabilise the platform, enhance the visualisations, and adapt the technology to their needs. The research team also faced hardware technology issues that needed to be physically addressed (frequent visits to the units to fix them). This last part helped the research team to improve technical guidelines and lessons-learned for future deployments in Singapore.

Discussion

In this paper, we have presented the approach of developing and deploying technology and services towards an ambient assistive living system for elderly people, details about pre-deployment steps such as the implication of formal and informal caregivers, and the involvement of the elderly users themselves.

From the user acceptance and engagement perspective, the requirements are mainly to provide services that enable understanding the lifestyle of the user and knowing if the elderly is safe at home. Trends are important added value to this first basis of data, and users may observe a decline or a progress in the several studied parameters such as the sleep quality of Activities of Daily Living metrics. For the formal caregivers, the system relieves the burden of manpower shortage in providing monitoring solutions that might ease the caregivers daily tasks. It will be a consistent base of information, and the data can be useful to adapt service proposition. Concerning the elderly participants, some might not want to retrieve any data about themselves, while others are willing to be active participants of the study. Therefore, methodology and approach must be adapted according to each user's profile and expectations of the project.

From a technical perspective, the system should guarantee privacy of users and should be reconfigurable, easily deployable, adaptable, and scalable. In order to cope with the technical problems resulting from hardware or infrastructure issues, the platform should be designed for failure, data mitigation, and system recovery.

In term of deployments and maintenance actions, a local structure needs to be established in order to send technicians on site quickly for either technology diagnostic or even sensors removal if a participant decides to quit the project.

Introduction

The deployment of our devices and software yielded data points coming from sensors, from software processing, as well as from meta-data sources.

The core of the resulting dataset comprises the time series from sensors readings (figs. 81 and 82). For home monitoring, motion and contact sensors along with sleep mat sensor were used. Mobility-related data originated from accelerometer and other IMU sensors of a smartphone. Fitness data about the step count was collected via a stable API. However, in home monitoring, because of network and configuration issues it was necessary to extract the data from secondary sources, such as system logs. In cases of file system corruption, a tertiary source was useda forensic analysis of the memory cards.

Reasoning Validation

As for the validation of the reasoning, tests have been performed in a controlled environment, in order to confirm the rules that were written manually as logical statements and conclusions. If the person is in kitchen, they are performing a kitchen activity, and if the fridge is manipulated, the person is probably preparing food.

Before the deployment, all hardware items to be deployed were tested. The sensors were placed in their respective location in redundancy. In this setting, all monitored virtual homes were supposed to send the same events at the same time. In this way, we could verify that all configurations were correct and the devices were ready for the participants' homes. The test lasted for a week, in order to verify the stability of the service. Figure 83 shows a screenshot of a test before the deployment.

Figure 83: Redundancy test of sensors before deployment. Sensors in the same room detect same events. The test uncovers some anomalies, e.g. the event is delayed or missing.

Moover: Usage statistics

As a part of the evaluation of the mobile application Moover, I implemented several methods of collecting meta-data about the usage of the application, presented in fig. 84.

Three types of events were successively implemented and are being collected up to this date: application download, reasoning process, and Fitbit synchronisation.

In an enhanced version, the application reports its usage and indicates when it was launched (after a crash or after a reboot of the mobile device), when it was displayed, and when it was left (switched to another application, hidden or closed).

Data presented in fig. 84 shows the usage statistics of several users during a period from 1st October to 28th July 2019. We can infer that the user interaction index is quite low. I attribute it to the choice made during the conception of the application -to not include user notifications that would make the user aware of the application. The choice may be reconsidered and despite the user's possible annoyance, it might be worth to make the application remind the user about itself. Three typical signal shapes are labelled according to recognized conditions: bed empty, bed motion, sleep. Gantt diagram: Row "B" is the result of the signal processing from the bed sensor. Row "M" shows a very inaccurate detection using motion sensors (blank space indicates activity detection in other rooms out of scope). Row "S" indicates the participant's answer in the survey table 4 about their waking and sleeping habits.

Crossing the Data with Questionnaires and Caregiver's Information

The proposed solution was deployed in real conditions for 30 days in order to validate our approach. During the deployment in participants' homes, our system recorded data, and they were post-processed and evaluated. The objective of this validation was to study the reliability of the sleep monitoring and the performance of the entire system in a distant real deployment. At the same time, this deployment allows us to validate the interconnectivity of different sensors, the communication between the gateway and the server, and presentation of results in real time. In order to validate our aggregated values, we performed individual interviews to understand the individual lifestyle of each participant. Table 4 presents an abstract of the results of the personal interviews. For instance, we detected that resident 1 started his bed activity very soon in the evening, and they woke up around 2.30 am. At first, it seemed to be an aberration in our measurement. However, in the survey, the resident confirmed her sleeping time matched our results. Thus, we could validate our inferred values.

Replay Results

As shown in fig. 89, the data loss was substantial. Application of low level data recovery techniques and extraction from logfiles and other components, we managed to recover more than 400 events in the displayed segment. The "replay" implementation yielded following results and observations that prove the feasibility of the approach. However other issues and open problems were discovered, notably leading to discovery of memory leaks in the platform.

Figure 89: Delayed events -illustration of a discrepancy between collected data in the gateway (977) and received in UbiSmart (507)

Parameters

For the actual replay test, we used a dataset containing 22 034 events covering 84 days of event data. After completing the dataset with 105 138 generated clock events indicating the points in time when the evaluation should take place, we obtained the total of 127 172 events to be replayed. The "clock events" were generated in the same way as the system would generate them in real-time mode: if the gap between two consequent events is more than 30 seconds, a "clock event" is inserted every 30 seconds in-between. Scheduling of clock events is illustrated in Source 8.

Source 8 -Example of scheduled events (in JSON format) with replay tag, showing 30-second delay of the inserted clock event.

1 { 2

"date": "2017-07-20T21:31:23.000Z",

3

"house": 101,

4

"sensor": "sleepMac _ b8",

5

"value": "Bed _ Occupied",

6

"id": 708409,

7

"createdAt": "2017-07-20T21:31:23.000Z",

8

"updatedAt": "2017-07-20T21:31:23.000Z",

9

"replay": true }, { "event": "clock", "date": "2017-07-20T21:31:53.000Z", "replay": true }, ...

This "clock event" timer parameter was chosen by tests with different values: with 10 seconds, the number of events was too high and with 10 minutes (600 seconds), the resolution of resulting reasoning was too low to activate rules that are capturing activities shorter than 10 minutes. As the event data came from the real deployment, we already had a dataset to compare with -the real-time inference. The parameters differences are summed up in table 5.

Execution

The execution of the replay was tested several times and the results were very similar.

The process was executed on x86_64 architecture virtual host with 2 400 MHz single CPU. For previously mentioned results in section 7.4, it took 78 hours and 58 minutes to complete (using 63 hours and 12 minutes of processor time) in our UbiSmart platform built with Node.js.

The extreme duration of the replay was unexpected. Detailed data from the replay executions were collected and a systematic anomaly was observed. Figure 90 illustrates a typical execution. This instance replayed a total of 220 334 events (38 362 original + 181 972 clock events every 60 seconds). The process took 10 days 20 minutes and 35 seconds. A systematic anomaly was observed across several tests. The performance declined, dropped to almost zero, and resumed continuation of the exponential decline. The drop in processed events lasted for a few days, in some instances till the end of the event queue. In an attempt of explanation further tests were performed to pinpoint the reason for such behaviour. Current hypothesis is that a memory leak has been present in the platform code that causes exponential decline. This hypothesis is supported by the experiment when the reasoning loop was skipped. In this way, the queueing mechanism seems to lose in performance, however no drastic drop of performance was not observed. Figure 90: Replay performance issue: Performance, measured as a number of events processed per hour (e/h) was not stable and showed anomalies. In first 11 hours, the performance gradually fell from initial 6 000 e/h to 3 000 e/h. Then, the pace dropped to only 10 e/h, remaining steady for 3 days and 11 hours. Sudden jump to 2 000 e/h was followed by a continuous exponential decline till the exhaustion of events to replay after 6 days and 3 hours. Total events: 220 334.

Observations

Resulting activities have been compared to a running instance in real time. The differences were observed and are illustrated in Figure 91. The expected differences that the replay displays are as follows:

1. higher activity granularity (darker colour indicates more short activities), 2. new activities previously undetected (nap between 00:00 and 03:00), 3. overflowing activities (18:00 to 20:00 nap, where it was not supposed to be detected). Minimum width of an activity representation is set to 5 pixels so that short activities are visible. If events are too close they visually overlap and appear in darker colour.

Discussion

The results highlight several questions around the proposed approach and its possible future.

Replay circumstances

As it can be clearly seen in the execution details in previous section, the replay is very resource intensive. Therefore, strategies for partial replay have to be considered for more effective resource use. For example, to store checkpoints of current state regularly and resume at a checkpoint to make it more efficient. However, depending on the ontology, the decision taken in the past can have impact deeply in the future. The question of handling such cases remains open.

We can distinguish two main motivations for such a replay: enhance the resulting dataset or enhance the decision process. For instance, in the first case, the priority is to provide the best results even if they come later; the second case might consider delaying certain decisions or make them more fuzzy if a certain type of data tends to arrive late. These two points of view are mutually compatible, and can lead to a richer event handling and greater user satisfaction.

Result management Replay implementation also opens a question about what to do with the old decisions. Shall we just replace them? If we keep them, how many layers of replay?

For our system, we decided to keep the older decisions in order to: keep track of the state of the system in the past (we have to know what an observer might have seen when looking at the system). This can also be used for a differential analysis. We label previous decisions as "disabled by [a reference to a new decision]". As for our use-case, the optimal solution is to keep the oldest decisions and the newest one. It allows us to explain why the notification was sent without confusing the end user (caregiver) with too many versions of what the activity might have been.

Impact on our platform In our case, the replay implementation helped to point out the difference between an uninterrupted operation of the platform during the replay and the case when the platform is interrupted and restarted. When the platform is restarted, we may lose some context information. Replay allows us to test these differences.

Another observation exposes some issues with previous implementation and brings a solution. It depended on the time when the event was effectively evaluated within the reasoner. In the case of processor overload, e.g. unrelated heavy processing on the server, the events queued and were processed much later. We were computing the duration of an activity as the time difference between the current machine time, and the first in an uninterrupted series of the same event. As a consequence, the activities appeared to have a longer duration than they actually had. Another reason of discrepancies was the misalignment of the clocks of event producer and consumer where we could get negative duration of an inferred activity.

Particularity of the execution was its non-uniformity in time. In the beginning, the execution pace was quick and at around two cycles per second. In the middle, the pace slowed down to as low as 2 minutes per cycle. At the end, the execution resumed a quick pace at one cycle per second.

Moover Results

The application was deployed to 36 users. The use of our engine and use of the application was monitored in the second version of the application.

Very few participants used the applications extensively. Many even stopped synchronising with the Fitbit tracker, which means they may have stopped using the tracer device or removed the permission.

We noticed several users downloading the application multiple times. After a further investigation, we could confirm issues with the installation and the first start.

It is a research which shows difficulties in testing; 15 out of 36 users downloaded the application but failed to set it up with Fitbit or make the reasoning work (e.g. not activated geolocation or location services thus the application did not allow them use it). Two downloaded the app, did not managed to use its reasoning process, but used Fitbit. 18 used the reasoning at least once. 6 did not use Fitbit, but used the reasoning at least once.

According to 17 valid profiles, the age of participants ranges from 22 to 59 years, with an average of 31.5 years and median of 30.

The feedback from our active users include following categorised statements: Data empowerment "The great power of data is when you can communicate it to people at an individual level that makes sense for them, for example: at a neighbourhood level . 7.6 System Performance two third participants find the application interesting. More than half participants judge the design more than satisfactory. Suggestion of a tutorial for walk-through was noted and likely to be implemented in a public release. We noted some a nonnegligible level of doubt for the credibility of the information. Figure 94 shows that only one third of participants trusted the application information sources. Others claimed that the sources are possibly trustworthy. In order to enhance the credibility, we will consider an implementation that states the sources for each information provided.

The mobile application has been tested by both younger and elders testing groups.

For few early stage testers, a full overview of the application had to be done during the installations in order to explain the application's functionalities and to go through the options.

Figure 94: Real-time data that is being displayed by the application is correct.

Transport information such as bus schedules are right and environmental data seems also relevant (in particular to the weather 2-hours forecast).

Figure 95: Ease of use of Moover application: Generally seen as easy to use.

System Performance

The analysis of the software that our team has created became an integral part of the development. Tools that analyse the software were a result of my efforts to automate tasks that could be done faster without having a human to do them. According to this paradigm of automation, I created a wide range of tools to maintain a connectivity, monitor different parts of the system, and gather and plot the indicators that were naturally available.

For instance, a monitoring system of the deployed gateways involving a maintained ssh connection to a central server and exposing the secured gateways on specific ports of a cloud server, allowing us to query indicators like core temperature, memory, CPU-load, technologies deployed. For Moover application, the analysis included monitoring of downloads, use of the application, and the reasoning in particular.

After noticing a problem during one of my contributions section 4.5.7, I managed to extract some indicators to quantify the problems and further investigate the causes.

Perspectives

The most prominent continuation of this thesis could be an automated generation generation of rules. The presented research and development provides some of required components to proceed with the automation: replay and validation table.

In the following way they fit in the larger picture of rules generation: The replay paradigm introduces the mechanism of moving back to a previous state and generating a new line of history. This allows us to test different sets of data and processing definitions in the long run. In contrast, the validation table test a set of rules against all defined combinations of inputs. Its output offers a way to evaluate the possible outcomes of a reasoning process which is very important in feedback loop.

One missing element to complete a version of automatic rule generation is the transition from human-based evaluation to human-in-the-loop evaluation -as we may want to take the responsibility for the decisions taken within the reasoning process.

A convenient and efficient user interface needs to be designed for the domain expert to pilot the system's learning process.

Another component to be developed is the suggestion module. Its role would be to create new rule suggestions based on the needs. Closely coupled with the user interface, it should be designed to extract the inspiration for the rules using the piloting user's inputs and taking into account needs of other stakeholders of the system. This component could make use of the large quantity of existing ontologies. An example of which might be to take into account connections and relations amongst available data points. Another valuable source could be making use of various data mining and pattern recognition techniques. Which, in turn will bring us to learn from and contribute to the field of data fusion.

Even though the current system implements logical assumptions about activities, it could be a valuable addition to develop wider and deeper behaviour recog-nition. More complex activity recognition can help us to characterise people's behaviour an provide further insights into individual well-being. In this regard, the work on concurrent or parallel activities could be valuable. It brings new model and new challenges.

The experience with the deployments points out that every person is special. And the more people participate, the more we understand the variety of needs, the more we can learn. Even larger scale deployments in terms of number of participants will provide more data. It is a crucial step towards understanding of personalised well-being and general as well as individual quality of life enhancement. This brings us to the robustness of the framework that has to be tested and ensured. In the process of designing and testing the contributions, several software anomalies were discovered (section 7.4.2). In future work it is necessary to address these practical issues to make sure the platform remains secure, reliable in a long run, and resilient in case of network problems.

The framework needs to evolve to match current technologies. The challenge is to support the majority of devices to make the technology available to everyone.

For that matter, we identified multi-platform technologies, such as Ionic and Flutter that allow us for a portable code compiling for multiple platforms, ensuring the compatibility layer.

Another important way to extend the semantic solutions is to perform more advanced analysis. Explainable Artificial Intelligence (e.g. Silas) has a lot of potential to bring the technologies of machine learning towards user's understanding. This, also referred to as Dependable Artificial Intelligence paradigm, promises being able to provide insights and make the system verifiable and trustworthy. Its possible coupling with the technologies of semantic web might bring a strong contribution to both fields. In a lower level, it means that the model and the structure of the data needs to be adapted and optimised for such use.

Conclusion

Ageing populations make societies face new challenges. To help living longer and healthier, we need not only assisting old people but also promote a healthy lifestyle. This thesis explores multiple real life applications of technology for quality of life improvements.

To introduce this thesis and set it in the current context, I reviewed potential technologies that can bring changes to the way we live. Among them, the Internet of things, the 5G, connected vehicles, low-power area networks. Current evolution of technologies is about connecting more and faster, while increasing reliability as well.

It is important to use the technologies for a common good.

Then, to share the state of the art, I reviewed the technologies that may be of use in our research, techniques for symbolic reasoning and its competing technologies. Those technologies are IoT for ambient assisted living, represented, for instance, by smart homes, smart environments, and wearable sensors. Particularly, the popularity and acceptability of fitness trackers makes them the leading devices for data collection. Either for research or for national challenges.

The symbolic reasoning still has an outstanding position on the field. The current research is investigating the ways how to combine rule-based approaches with machine learning. The challenge is to benefit from the possibility of explanation of decisions of rigid rule-based system and the automated approaches in machine learning. Rule generation is one of the promising directions. The machine could learn to suggest rules that will be available for validation by the responsible expert. A pure rulebased system still offers an advantage of having low computational footprint if well designed and the space of using machine learning for partial tasks as sub-modules is an option of a weak integration of both.

To explain the design of semantic systems, I present the theoretical foundations behind the practical implementations. Description logic formalises what is the concepts of common sense and provides terms for interpretations.

The chapter about the development provides an overview of my contributions to UbiSmart framework. Notably, the replay service and the concept of parallel activities detection. Other contributions account for software engineering but they were essential for the progress and maintenance of the experimentations. These include monitoring services and integration of new kinds of sensors.

Following chapter tracks the development of a research oriented mobile application "Moover". An intense collaboration gave way to a viable application. The particular case of the validation method by table generated from the rules allowed for the verification of the reasoning process that is usually a complex task having to cover an extreme multitude of unforeseen cases. Offering simple interface and integrating environmental resources, it is a unique application oriented on active mobility.

Putting the designed and implemented technological solutions to the test is the subject of the chapter about deployments. All work was deployed in Singapore and its dynamic environment, welcoming efforts of technological innovation within clear regulations. Projects that benefited of this work are presented as well. Among four of them, two are European projects having Singapore as one of their pilot site: City4Age targeting better quality of life for old people, ans PULSE project examining the urban environment and better life within. Both used the platform for data collection, visualisation and processing. Another collaboration includes a hospital, where the platform served to advance my colleague's work on sleep apnea. Last but the most important collaboration is with the industrial partner PSA Group. This was the direct collaboration centred around the full stack deployment of the mobile application.

To conclude, this thesis makes an effort to enhance the services for keeping us active, in good health and keeping an eye on us, while respecting the security and privacy concerns. Its result is a contribution to a technological infrastructure for innovative solutions. It also brings several concrete implementations. These implementations are empirically tested, deployed and continuously enhanced.

  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Wider Context of the Thesis . . . . . . . . . . . . . . . . 2 1.3 Demographic Issues . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Chronic Diseases . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Interest in Technology . . . . . . . . . . . . . . . . . . . . 9 1.6 Impact of Internet of Things & 5G . . . . . . . . . . . . . 9 1.7 Impact of Artificial Intelligence . . . . . . . . . . . . . . . 20 1.8 Thesis Contribution . . . . . . . . . . . . . . . . . . . . . . 21 1.9 Organisation of Manuscript . . . . . . . . . . . . . . . . . 23

Figure 1 :

 1 Figure 1: Probabilistic prediction of world population evolution in the UN report on population, 2019 revision: (a) total world population, (b) world population over age of 60. Source: United Nations, Department of Economic and Social Affairs, Population Division (2019); World Population Prospects: The 2019 Revision https://population.un.org/wpp

Figure 2 :

 2 Figure 2: Projection of ageing population till 2050. Data source: United Nations (2017). World Population Prospects: the 2017 Revision

Figure 3 :

 3 Figure 3: Estimates of diabletes prevalence in Singapore according to IDF and to governmental open data. Different age groups and metrics explain the difference.

Figure 4 :

 4 Figure 4: Architecture similarity: supercomputer and terminals

Figure 5 :

 5 Figure 5: Car automation levels according to the Society of Automotive Engineers Reprint from National Highway Traffic Safety Administration (USA) (NHTSA)

Figure 7 :

 7 Figure 7: Download experience in the world's 4G networks in January -March 2019.Source: Opensignal

Figure 11 :

 11 Figure 11: Smart watches, wrist bands and bracelets. (a) Apple Watch -smart watch, (b) Samsung Gear 3 -smart watch, (c) Fitbit Versa -smart watch, (d) Fitbit Charge 3 -fitness wristband)

  It operates smart watches made by Samsung, LG, Motorola, Huawei or Mobvoi. Another open-source alternative OS Tizen Wear maintained by Linux Foundation used in more recent Samsung watches that connect to either Android and iOS devices. Simpler devices, mostly fitness trackers operate under custom-made closed-source firmware. Examples include trackers and watches by Fitbit and Garmin. They connect to Android, iOS and also Windows Phone devices. The pairing of the wristband or smart watch to a smartphone makes the wearable its extension. The wearable then can receive notifications from the smartphone or it can perform a wireless payment. Smart watches and wristbands have basic function of showing time or setting an alarm clock. Smaller devices are suitable for sleep tracking. Fitbit trackers provide a detection of sleep phases (e.g. Charge 2, Charge 3, Alta HR), including a recent measure of the quality of the sleep.

Figure

  Figure 12: SenSg device

Figure 13 :

 13 Figure 13: Bluetooth beacons (a) and tags (b)

Figure 14 :

 14 Figure 14: Various smart wearables: (a) socks, (b, c, d) T-shirts, (e) umbrella, (f) walking stick

  with a state of the art of semantic reasoners, explaining the choice of Euler YAP Engine (EYE) reasoning engine [De Roo 2013], the Notation3 (N3) language [Berners-Lee & Connolly 2011] and the Notation3 Logic (N3Logic) logical framework [Berners-Lee et al. 2008].

Figure 16 :

 16 Figure 16: Activity inference semantic model (T-Box) as defined by Thibaut Tiberghien

  maxSleepMotion} => {hom:sleep :getScore 6}. {?u qol:believedToDo hom:sleep. ?u qol:doesActivityFor ?d. ?d math:notLessThan ?u!prof: maxSleepDuration} => {hom:sleep :getScore -5}. ## fall {?u qol:believedToDo hom:nothing. ?u qol:doesActivityFor ?d. ?d math:notLessThan ?u!prof: maxInactiveDuration} => {hom:fall :getScore 8}.

  Source 4 -N3 Rules for Arbitration @prefix e: <http://eulersharp.sourceforge.net/2003/03swap/log-rules#>.## definition of localy useful property:getFinalScore a rdf:DatatypeProperty; rdfs:comment "Computed total score over all single-rule scores."@en; rdfs:domain qol:Activity; rdfs:range xsd:int.## sum scores and compute confidence [live only]## if no activity stand out then give score to hom:nothing [live only]

  . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . 50 3.3 Scientific Challenges . . . . . . . . . . . . . . . . . . . . . 51 3.4 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.5 System Components . . . . . . . . . . . . . . . . . . . . . 61 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

  a Healthy Lifestyle 2. Cope with a busy professional agenda 3. Meet her friends for her weekly volleyball training Susan in the "Preventing Tiredness" scenario:

  Keywords: Family, lifestyle coaching, in-car health monitoring, Diabetes, long distance mobility, physical activity, quantified self, caregivers C. Use-case 3 -Breathe well (refer to video demo) Name: John Yeo Age: 40 Position: Grab taxi driver and barista Goals: 1. Continue to work despite respiratory problems 2. Get some help in maintaining an active lifestyle 3. Manage his mobility in the city John in "Breathe well" scenario:

Figure 18 :

 18 Figure 18: Rules from initialization, categorization, adjustments and computations

Figure 19 :

 19 Figure 19: Snapshot of UbiSmart's "replay" service's instantiated ontology knowledge base selection containing information of the user (hom:johndoe).

Figure 20 :

 20 Figure 20: Ontology hierarchy (links and classes, i.e. concepts) adapted to mobility aspects and specific frailty

Figure 22 :

 22 Figure 22: Upper part "Reality" depicts what happens and when it happens. Lower part "Description" is how the reality is represented in our system. A simple cycle of reasoning with one event that triggers a start of activity A. Highlighted parts show what elements are taken into account during the reasoning cycle.

Figure 23 :

 23 Figure 23: A second cycle of reasoning triggered by a timer event, extending activity A.

FigureFigure 27 :

 27 Figure 26: Ubismart platform simplified schema

Figure 28 :

 28 Figure 28: Feedback from simple self-monitoring application collected during 1 month of deployment. All feedback datapoints were positive with one exception.

Figure 29 :

 29 Figure 29: Example of instantiation of UbiSmart from different git repositories:UbiSmart core, ubiservices and reasoning. Components inside the system can be exchanged or added during the runtime.

Figure 30 :

 30 Figure 30: Data flows between hardware components of UbiSmart ecosystem.

Figure 31 :

 31 Figure 31: Raspberry Pi 3 Model B

Figure 33 :Figure 34 :

 3334 Figure 33: Mobile 3G router to provide Wi-Fi connectivity. Aeotec sensors We used two types of Aeotec sensors "MultiSenor 6" fig. 34(a) and contact sensor fig. 34(b). In order to collect the data, the receiver "Z-Stick" fig. 34(c) was deployed. Z-Wave sensors allow routing among nodes. It means that a node (sensor) does not require a direct connection to the gateway equipped with Z-Stick but can reach it through other nodes. As mentioned in [Badenhop et al. 2017], Z-Wave protocol allows up to 4 hops in the relay chain. Motion sensors have a very particular configuration. [4 minutes delay between last detected motion]

Figure 36 :

 36 Figure 36: UbiSmart framework in three sections. The UbiGate, the Server and the Service Provisioning.

Figure 37 :

 37 Figure 37: Domoticz interface for device management

Figure 41 :

 41 Figure 41: The interface of GNU Screen for Raspberry Pi gateways

Figure 42 :

 42 Figure 42: The interface of Tmux environment in remote servers for development and production.

Figure 44 :

 44 Figure 44: UbiSmart "event-statistics" visualisation provides a large overview of count of sensor events across the deployment for each day

Figure 45 :

 45 Figure 45: UbiSmart "life-tiles" visualisation summarizes daily activity data

Figure 46 :

 46 Figure 46: UbiSmart "senslog" visualisation featuring the navigation within the historical data

Figure 48 :

 48 Figure 48: UbiSmart "ontolive" default visualisation lets the user see what is the current content of a knowledge base for a given house

Figure 49 :

 49 Figure 49: UbiSmart "ontolive" visualisation providing a structural view of the current state of the knowledge base

Figure 51 :

 51 Figure 51: Simulation View: selecting conditions (sleep quality and quantity, current weather) modifies the recommended mobilities in the mobile application

  54. The development started in April 2018 when the Singapore Android market share was 83%. As of October 2019, Android market share reached 65% and has a growing trend.

Figure 54 :

 54 Figure 54: Evolution of market shares of different operating systems in Singapore for mobile devices (smartphones, tablets, ...) between January 2018 and October 2019. Data source: StatCounter

Figure 55 :

 55 Figure 55: Annotated mobility modes as detected by Google API for Android during a commute from work to home on 10th April 2018 (time is UTC + 8 h).

Figure 57 :

 57 Figure 57: Activity detected displayed in UbiSmart web interface

-

  CaloriesOut -estimate of calories burnt by the user -Distances -estimate of the distance walked by the user -Elevation -cumulated positive altitude change -Floors -number of floors climbed during a day -LightlyActiveMinutes -minutes of activity (walking) -SedentaryActiveMinutes -minutes user was inactive -VeryActiveMinutes -more intense activity duration (running, exercise)

Figure 58 :

 58 Figure 58: Fitbit's authorization page

Figure 59 :

 59 Figure 59: Example Request

Figure 61 :

 61 Figure 61: ActiviGate version 2 application overview: welcome screen, authentication to UbiSmart, data presentation

Figure 64 :

 64 Figure 64: Fitbit subscription API diagram, modified from Fitbit documentation https://dev.fitbit.com/build/reference/web-api/subscriptions

Figure 65 :

 65 Figure 65: Moover screens: (a) welcome screen, (b) login screen, (c) user profile

Figure 66 :

 66 Figure 66: On the left (a) bike mobility solution. On the right (b) bus mobility solution.

Figure 67 :

 67 Figure 67: (a) Example of coloured recommendation for different mobility solutions. (b) Activity screen

•

  Status: success / fail • Mobility: Mobility solutions scores • Temperature: temperature value • AQI: Air Quality value • Description: Weather description to set the weather icon

Figure 68 :

 68 Figure 68: Moover integration in UbiSmart framework

Figure 69 :

 69 Figure 69: Six dimensions for each mobility solution as implemented in our application

Figure 70 :

 70 Figure 70: Mobility solution recommendation cell. Depicted cell shows scores for conditions of asthma, no disability, outdoor temperature being under 36°C, fair weather, air quality categorised as unhealthy.

Figure 71 :

 71 Figure 71: Moover flyer campaign

Figure 74 :

 74 Figure 74: Compact overview of sensor events over 3 years. Rows represent homes identified by numbers, each containing several tracks -sensors. Each dot is one or more sensor events. Colours indicate type of events: greenmotion on; red -motion off; orange -contact open; blue -contact closed; purple -bed on; black -other

Figure 75 :

 75 Figure 75: Sleep mat integration at the three HDB apartments; (a) 1 st home with mat under bed mattress, (b) 2 nd home with mat under sleeping rug, (c) 3 rd home with mat under bed mattress.

Figure 76 :

 76 Figure 76: Discharge of batteries during a long term deployment. Some sensors indicate full battery charge as values 255 and some 100. All three motion sensors start at the value 50 (because they operate only with one battery instead of two). Possibly a firmware version and internal configuration of the sensor might differ. The values stayed unchanged for more than 180 days without intervention. Sensor "Motion26BBedroom" stopped its operation on day 185. Sensor "Motion26AToilet" is visibly discharging since day 184.

Figure 77 :

 77 Figure 77: Dashboards used as monitoring tools.

Figure 78 :

 78 Figure 78: User-friendly interface showing data as readable metrics and score

Figure 80

 80 Figure 80 shows an example of graphical and statistic sleep analysis.

Figure 79 :

 79 Figure 79: Visual data investigation by overlaying everyday of the month and comparing each month evolution.

Figure 80 :

 80 Figure 80: Sleep data of one participant over time and monitoring trend and sliding average.

Figure 81 :

 81 Figure 81: Daily performance during three deployments in Singapore (1 = Geylang Bahru 2016, 2 = Geylang Bahru 2017, 3 = Teck Ghee 2018-2019). The histogram shows the counts of sensors per home (N=25) that have sent at least 1 event that day.

Figure 82 :

 82 Figure 82: Daily performance during three deployments in Singapore (1 = Geylang Bahru 2016, 2 = Geylang Bahru 2017, 3 = Teck Ghee 2018-2019). The histogram shows the counts of sensor events per home (N=25).

Figure 84 :

 84 Figure 84: Moover usage in April 2019 to August 2019. User activities are plotted rows. The shape indicates the type of the activity. Usual order of activities is download of the application, interaction, reasoning, Fitbit synchronisation. Some users have not updated the application to provide interaction statistics.

Figure 85 :

 85 Figure 85: Representation of a participant's night from our real life deployment.Three typical signal shapes are labelled according to recognized conditions: bed empty, bed motion, sleep. Gantt diagram: Row "B" is the result of the signal processing from the bed sensor. Row "M" shows a very inaccurate detection using motion sensors (blank space indicates activity detection in other rooms out of scope). Row "S" indicates the participant's answer in the survey table 4 about their waking and sleeping habits.

Figure 86 :

 86 Figure 86: Sleep mat: (a) Longitudinal section of the microbend fibre-optic sensor, (b) Sleep mat and processing box. (Mat dimensions: 20 cm × 50 cm × 0.5 cm) (c) Sleep mat positioned under the mattress.

  processed per hour during a replay on home h20 (2018: March -December) [UTC +0000] logarithmic scale linear scale

Figure 92 :

 92 Figure 92: 71,5% of the users find the application interesting to use, with 42,9%being enthusiast by the concept of the Moover application together with its benefits for the health.

Figure 93 :

 93 Figure 93: The development of the application has been pushed to the users on aniterative way, and some functionalities linked with the overall design of the application has been improved.

  . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

24 2.2 IoT for Ambient Assisted Living and Mobility Applica- tions

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Reasoning Indoors and Outdoors . . . . . . . . . . . . . .

Contents 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .

38 2.4 Semantic Model for the Activity Inference

  . . . . . . . . 41 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Table 1 :

 1 . Overview of home automation platforms

	Name	Prog. language	License	Notes
	OpenHAB	Java	Eclipse Public
	Domoticz	C/C++	GPL v3
	Jeedom	PHP & C/C++ GPL v2	Linux+Android & iOS
	Home Assistant	Python	MIT
	Calaos	C++	GPL v3
	EventGhost	Python	GPL v2	MS Windows PCs
	ioBroker	JavaScript	MIT license	Node.js-based
	LinuxMCE	C++	Pluto	Linux; video games
	OpenNetHome	Java	GPLv3
	Smarthomatic	Eagle	GPLv3	2013 -2017
	HomeKit	-	Apple
	Mozilla WebThings JavaScript	Mozilla Public 2.0

4 Development of "UbiSmart" Platform Contents 4.1 Introduction

  . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2 Development Strategy & Structure . . . . . . . . . . . . . 69 4.3 Hardware Architecture . . . . . . . . . . . . . . . . . . . . 71 4.4 Hardware and Software Configurations . . . . . . . . . . 73 4.5 Software Implementation (Backend) . . . . . . . . . . . .

76 4.6 Service Implementations (Frontend) . . . . . . . . . . . . 85 4.1 Introduction Ubiquitous Service MAnagement & Reasoning archiTecture (UbiSmart) is a customised framework previously developed by the laboratory's research team in a research collaboration. It was built on Sails.js web platform to handle a large-scale deployment. This framework is well suited for agile development, offering high levels of versatility and plug & play features, which facilitate the active participation of the users. UbiSmart is a general purpose web-based AAL framework. This chapter presents my development contributions to this platform.

6.3.4 KTPH: Khoo Teck Puat Hospital Collaboration Hospitals

  and medical centres are also key stakeholders for the local development of the solution. Close collaboration with hospitals, such as Khoo Teck Puat Hospital, has been instantiated. The collaboration comprises of scientific conception, technical development, deployment, data analysis, and validation. KTPH, a 659-bed general and acute care hospital, opened in June 2010. Serving more than 700,000 people living in the northern sector of Singapore, KTPH combines medical expertise with high standards of personalised care, set within a healing environment, to provide quality care. From intuitive wayfinding to logical clustering of services, KTPH's design focuses on providing a hassle-free experience for patients.

  The pilot site is Coordinated by CNRS and is collaborating with the local authority of Montpellier Metropolis and healthcare professionals from Beausoleil Clinic and Saint Vincent De Paul nursing home. The pilot site is being conducted in two different cities: The city of Lattes and the city of Argentan. 19 participants have been recruited and equipped with the City4Age solution in both the two cities. A total of 267.092 LEA and 39.238 measures related to these participants have been collected for around one and half a year. These data and related geriatric factors and sub-factors are accessible through the City4Age dashboard for interpretation, assessment and intervention. This application also has to follow the Ministry of Health (MOH) guidelines. For the Singapore Pilot Site, CNRS follows the procedure established by the National University of Singapore (NUS) Institutional Review Board (IRB). An Institutional Review Board (IRB) is an independent committee established within the university that conducts scientific and ethical review on research involving human research participants. The purpose of the IRB is to review all human participant research proposals before the research is conducted. IRB monitors research, by way of receiving feedback, continuing review or regular reports, as determined by the IRB. The NUS-IRB follows the Singapore Good Clinical Practice GCP, ICH Good Clinical Practice GCP guidelines, BAC guidelines and the applicable laws and regulations of Singapore. Relevant information about personal data description and research data which have been included in the confidentiality & privacy part for the ethical approval application, are reported for completeness: personal data information sheets including name, address and phone number are kept separated from the research data and a code is used to identify the participant.

	6.4 Methodology 6.4.1 Local IRB CNRS team has to submit its ethical application (Singapore pilot) to the NUS Insti-tutional Review Board (NUS-IRB) in order to deploy locally or to perform subject All subject-related phases are performed with the help and active involvement of the Senior Activity caregivers and staff when it comes to organising recruitment and engagement sessions together with technical deployments sessions and interview / surveys. Month Activities Type Description M1 Development and approvals Observations, Discussions and Prototyping M3 Validation and Demo M3 Application for ethics approvals M5 Recruitment and Pre-deployment Initial Trial and field test M5 Briefing sessions M6 Recruitment sessions and Consent forms M6 In-depth interview and questionnaires M7 Deployment, Groundtruth and Data Analysis Deployments and interviews M8 Feature updates and Maintenances M10 Questionnaire surveys and fine-tuning M11 Feature updates and Maintenances M12 User engagement surveys M12 Data Analysis and feedbacks collection related studies. 6.4.2 Recruitment M14 Post-deployment Interviews on impact validation

Table 2 :

 2 Global timeline from user needs to deployments, particular case of Geylang Bahru Phases 1 and 2

Table 3 :

 3 Deployment technological packages and repartition.

		Package	Location		Timeline	Homes
		Features	Singapore	Duration	Starting date count
	A	Pi2, eth, Juvo1, X10, happy	Geylang Bahru 1 Month	August 2016	3
	B1 Pi3, 3G, Juvo2, X10, ssh	Geylang Bahru 6+ Months March 2017	5
	B2 Pi3, 3G, Juvo2, ZW, ssh	Geylang Bahru 6+ Months March 2017	5
	C	Pi3, 3G, Juvo2, ZW, ssh, beacons Ang Mo Kio	9+ Months May 2018	6

Table 4 :

 4 Sleep profiles of participants in 2016 phase 1 deployment in Geylang Bahru (no chronic diseases or disabilities are reported).

	Age	Living Situation	Sleep Time (approx)	Wake up Time (approx)	Nap
	1 68	Family	18:30 -19:30 Sometimes 22:00	02:30	2 -3 times 14:00 -15:00 pm 30 minutes
	2 69	Alone	23:00 -00:00	07:00 Weekends 05:30	1 -2 times 14:00 -15:00 30 -60 minutes
	3 65	Family	21:00 -23:00	07:00 Wednesday 04:00	Not reported

Table 5 :

 5 Parameters for real-time run and for replay.

	Parameter	Real-time reasoning	Replay
	"Clock event" timer	10 minutes	30 seconds
	max.	spacing between
	events
	Delay between event time	delay between event time-stamp	1 second
	and current time variable	and hardware clock at processing
			time
	Activity change	nap	occupied

  Figure 91: Samples of inferred activities from the same set of events. Upper graphics is real-time inference, lower image is replay with shorter timer duration.

	kitchen activity
	bed activity
	watch TV
	nap
	Wed 14 Jun 18:00	Wed 14 Jun 21:00	Thu 15 Jun 00:00	Thu 15 Jun 03:00	Thu 15 Jun 06:00	Thu 15 Jun 09:00	Thu 15 Jun 12:00	Thu 15 Jun 15:00
	kitchen activity
	bed_activity
	watch TV
	nap
	Wed 14 Jun 18:00	Wed 14 Jun 21:00	Thu 15 Jun 00:00	Thu 15 Jun 03:00	Thu 15 Jun 06:00	Thu 15 Jun 09:00	Thu 15 Jun 12:00	Thu 15 Jun 15:00

  . . this is what air pollution looks like around you; what it means for you; and what the advice is."Near geolocated data "Using the mobile App together with the wearable device is motivating, this is my one-stop-app for my personal data activity crossed with impactful Urban data. Those data are geo-located and enhance the use of the public space for citizens."

[GitHub, Inc.

2019] one of the largest platforms reports over 40 million users including over 10 million that joined in 2019

According to Pew Research Center survey in February 2019, in the United States [the U.S.], 96 % of the adult population owns a cellphone, while 81 % owns a smartphone.https://web.archive. org/web/20190817183647/https://www.pewinternet.org/fact-sheet/mobile/

https://kenstechtips.com/index.php/download-speeds-2g-3g-and-4g-actual-meaning

Opensignal report per country between 1st January and 31st March 2019 features 87 countries with South Korea on the top with

Mbps and Iraq in the last position with only 1.6 Mbps. China was not part of the sample. The overall average for 87 countries was 17.6 Mbps for download throughput experience. https://www.opensignal.com/sites/opensignal-com/ files/data/reports/global/data-2019-05/the _ state _ of _ mobile _ experience _ may _ 2019 _ 0.pdf https://www.opensignal.com/reports/2018/02/state-of-lte, their overview 5 A popular video-on-demand provider Netflix recommends on their website: For Ultra HD quality "A steady internet connection speed of 25 megabits per second or higher.", For HD quality: 5 Mbps. (https://web.archive.org/web/20190807013549/https://help.netflix.com/en/ node/13444)

https://web.archive.org/web/20190711044735/https://www.digitaltrends.com/mobile/5g-vs-4g/

https://tdwi.org/articles/2016/11/15/beer-and-diapers-impossible-correlation.aspx

SenSg SenSg device (fig.12) contains sensors that measure humidity and ambient temperature, air pressure, temperature of another object, sound pressure, light intensity, in addition to acceleration via an Inertial Measurement Unit (IMU). Algorithms are used on these measures to infer step count, mode of transportation, and indoor/outdoor detection. The device was developed as part of the "Singapore National Science Experiment", an island-wide initiative for students which was launched in 2015. The pilot phase from May to July 2015 saw the participation of 300 students from primary and secondary schools, and this was followed by over

https://www.computerworld.com/article/2881178/office-complex-implants-rfid-chips-in-employees-hands. html

http://www.openzwave.com/

https://www.figma.com

http://www.pastaproject.eu/fileadmin/editor-upload/sitecontent/Publications/documents/ PASTA _ LessonsFromHealthImpactAssessment.pdf

https://gs.statcounter.com/faq#methodology

https://gs.statcounter.com/os-market-share/mobile/singapore/#monthly-201801-201910

https://developers.google.com/location-context/activity-recognition

http://www.hdb.gov.sg Housing & Development Board is a Singaporean governmental organization responsible for public housing, on their website, HDB claims: "HDB flats are home to over 80 % of Singapore's resident population"

Mobile Application "Moover"

It is necessary to note that despite the initial interest in this feature, the custommade activity recognition was not yet included in the latest Moover application.

We opted for a very simple interface with minimal interaction, as illustrated in fig. 56. User is allowed to toggle the activity recognition on and off. The recognition is performed as a background task. It means that the sensing works while the application is not shown on the smartphone's screen. Every detected activity is stored in the device's memory until our server is reachable, i.e. the Internet connection is available. If the connection is available new activities are being sent directly.

The data provided to our servers arrives as if issued from a sensor named "mobility" and integrates in UbiSmart in a way that is illustrated in fig. 57.

The picture shows a portion of one hour a day. Rectangle highlights the events provided by the activity recognition API. We can notice that the events are not spaced regularly. This is due to internal resource management and optimisation that saves the resources while the screen is off.

Introduction

The work presented in this thesis has been put in practice in the city state of Singapore and I assisted personally in the deployment of the technologies. It concerned preparation of deployment sets, installation of the devices in participating households, distributing devices during meetings with participants, and complying with the rules for data collection and analysis. The deployments also directly contributed to several projects. This chapter presents the local context, the projects and gives insight into the process and the experience with the deployment process.

Local Context

Singapore is a small country with its inhabitants having a high level of trust in their government. It is possible to attribute this to the government's aggressive and successful reduction of corruption, using a strong repressive component towards offenders. This helps to create a good impression of the government taking such crimes seriously and taking actions to address them. At the same time, 80 % of the population lives in state-owned rental flats with a 99-year lease.

In order to be able to perform testing of the system in real conditions -in the homes of participants (schematic view fig. 72, actual 3D-model of the deployment site fig. 73). Exhaustive processes are necessary to allow researchers to deploy the system. However, the procedures to obtain permissions are less complicated than in some other countries.

Projects

The work presented in this thesis also contributed to several European projects.

Collected data from our elderly participants has contributed to the City4Age project.

The platform and younger participants contributed to Pulse project that studied sustainable urban environment. A technical solutions in sleep tracking contributed to the collaboration with Khoo Teck Puat Hospital (KTPH). The deployment of "Moover" application and the backend reasoning strategy was a direct contribution to the collaboration with PSA. This section introduces these projects.

H2020 City4Age: Elderly-friendly City Services for Active and Healthy Ageing

City4Age is a H2020 European project under Grant agreement ID: 689731 funded on Research and Innovation action (RIA) scheme. The project started early December 2015 and finished at the end of November 2018.

The first and core objective of City4Age is to enable Ambient Assisted Cities or Age-friendly Cities, where the urban communities of elderly people living in Smart Cities are provided with a range of ICT tools and services that -in a completely unobtrusive manner -will improve the early detection of risks related to cognitive impairments and frailty while they are at home or in the move within the city. The second objective is to provide a range of associated tools and services which -with the appropriate interventions -will mitigate the detected risks. The final objective of C4A is to define a model which will provide sustainability and extensibility to the offered services and tools by addressing the unmet needs of the elderly population in terms of (i) detecting risks related to other health type problems, (ii) stimulating and providing incentives to remain active, involved and engaged, (iii) creating an ecosystem for multi-sided market by matching needs and their fulfilment, (iv) contributing to the design and operation of the ultimate Age-friendly City, where the city itself provides support for detecting risks and providing interventions to those affected by mild cognitive impairment (MCI) and frailty. To achieve these objectives City4Age builds on:

• behavioural, sociological and clinical research on "frailty" and MCI in the elderly population;

• state-of-the-art ICT technology (i) for "sensing" personal data and exposing them as linked open data, (ii) for designing the algorithms and the API's to extract relevant behaviour changes and correlated risks, and (iii) for designing interventions to counter the risks, About the concept of service "Encouraging the people to be physically active and crossing this data with urban data makes sense to empower individuals in their daily lifestyle." Behaviour change "The mobile app enables to track your physical activity, it is very motivating. For instance, I will more likely try to walk or run more, also simple changes have an important impact on our daily lives, for example I take the stairs instead of the escalators to exit the subway. The sport side of the project, improving my physical activity is my main motivation."

We asked participants about the ease of use of the application and the feedback was used to solve technical issues. The need of the walk-through the application was noted and scheduled for a further release.

User Engagement and Validation

All subject-related phases are performed with the help and active involvement of the above described partners, especially with the Senior Activity caregivers and staff when it comes to organising recruitment and engagement sessions together with technical deployments sessions and interviews/surveys.

The steps are the following:

1. General presentation: public presentation of Moover mobile application.

2. Briefing sessions: volunteer participants who want to be involved in the project get a specific project review and practical matters are discussed. Technology devices are introduced to the participants and Q&A sessions enable a good understanding and project's scope.

3. Recruitment sessions: this is a crucial step, ensuring the participants are engaged in the project and do feel involved in the following steps. At this stage, participants are given the Consent forms, and the Participant Information Sheet are reviewed together to ensure a smooth experimentation.

4. Deployment and survey: during the whole duration of the project, a contact with the participants is maintained in order to make sure all operations are smooth. Overall deployment and user's acceptance are evaluated.

5. Post-deployment interviews.

The following results were obtained on criteria of general interest of the application (fig. 92), its user interface (fig. 93), source credibility (fig. 94), and ease of use (fig. 95). In total 7 participants answered the questions. Results show that more than