Using IoT for Accessible Tourism in Smart Cities

2.1. Security requirements

By the year 2020, worldwide there will be 50 billion connected devices [13], accounting for a mean value of 6 devices pro capita. IoT platforms aggregating data imply that these devices can be accessible over the Internet. Data networks, especially poorly configure ones, are vulnerable to all kind of attacks. IoT environments, always connected to the Internet, are not at all different, therefore there is the need for solid security mechanisms, which, specifically for a Smart City environment can be summarized in the following form:

1. Data encryption and security mechanisms: In most of the cases, data is more vulnerable when it’s in transit using cabled or wireless transmission methods because most of the services encrypt data only when it gets to the data center. The challenge here is to enable end-to-end security by making the entire authentication happen without the user’s intervention, so the data encrypts automatically at the source.

2. Hardened cloud infrastructure: Hosting data in the cloud can be far more secure than keeping in a data center but the cloud infrastructure may be also subject to attacks. ISO 27001 is a security certification standard that specifies security management best-practices and controls for data centers and cloud environments.

3. Activity logging: For both developers and users, activity logging is an important part of the intrinsic security of an IoT platform. Especially in a Smart City environment, and specifically for the present use case with large amounts of sensor data triggering certain actions, logging is critical for monitoring the functionality of the platform and to contrast possible malfunctions and security breaches.

2.2. Flexibility

The IoT market is still in its early stages of adoption, as it is also the case for the Smart City concept. The next generation of connected devices and products needs to rely on a certain software flexibility and for these reasons, an IoT platform in a Smart City environment should comply with following flexibility rules [15]:

1. Device agnosticism: The changes in the configuration of a device should be limited to updating the driver and at maximum the data format when adding or updating a devices, allowing hardware developers to develop their new generations of products without being limited by legacy or compatibility issues.

2. Device manageability: An inherent characteristic of a Smart Cities deployment is that the devices and sensors are placed at large distances in a Smart City environment, the IoT platform has to include methods for the remote management of devices.

3. Usage of open APIs: The devices and sensors present in a Smart City context inherently generate large amounts of data. It can happen that a conspicuous amount of this data remains not analyzed due to its unavailability to other users than the ones originally intended. The IoT platforms should therefore allow the access to shareable data, becoming like this a true motor for future innovative applications.

2.3. Data requirements

The data in the IoT world comes mainly from things but can also arrive in the form of metadata from users. IoT and Smart Cities are more than a sink for incoming data, data intelligence being the key concept. This implies relatively strict requirements in terms of data [13, 14]:

1. Data processing and analytics services: An IoT platform’s usefulness is given by its ability to process the collected data and turn it to usable information.

2. Data scalability: Especially in a Smart City environment the amount of IoT data has the tendency to grow fast, for example when monitoring environmental data. The IoT platform should therefore have the necessary features in order to manage the data using archiviation and culling methods, preferably fully automated.

4.1. Proposed architecture

The proposed platform relies on the Cloud IoT architecture [25], named Lysis, organized on four distinct levels (Figure 1). Service discovery and information exchange do not need objects to be in vicinity of each other, since they take place in the virtual world through the exploit of social relations.

In the following the four levels as described in details: the highest level is the Application Layer in which user-oriented applications are deployed; the Service Layer is responsible to receive the application requests and map them to the atomic services available in the lower layer; this layer is the Virtualization Layer, which interfaces directly with the real world and enhances objects’ functionalities; the last level is the Real World Layer, containing the real physical devices of the Smart City. Two additional cross-layers are needed to manage the quality requirements of the applications and to ensure that every communication takes place in a trustworthy and secure way, according to the previously listed requirements.

This approach has manifold motivations: (i) it enables objects to speak the same language at the virtual level; (ii) it enhances the service search and discovery; (iii) it decouples the service requests and the actual IoT objects which satisfy the request and (iv) it offers personalized experience to users based on their own needs and traits.

In the following paragraphs, we describe in detail the layers proposed for the architecture.

1. (1) Application layer: This is where user applications are deployed. Each application is composed of two interfaces: a front-end interface, which represent the access point for users or objects to interact with the system, and a back-end interface, which connects this layer to the rest of the platform and enables the application to be fulfilled by the lower layer.

2. (2) Service layer: At this level, service requests are analyzed and augmented with a range of facts concerning the human user, including user context, the type of disability, his/her profile, the preferences in terms of PoI categories and security policies.

The Service Request Analysis (SRA) receives the query from the Application layer and interact with the User Characterization block to obtain information regarding the user and the context in which the query has been made.

In particular, the User Characterization (UC) includes all the knowledge the system has accumulated regarding each user interacting with the system and his/her preferences. This block has then the ability to complement the query with additional information so that each application is truly personalized based on the user. This is an important component in our platform because many applications in a Smart City scenario, such as the one for sustainable tourism, are characterized by personal choices: requests coming from different users can have different solutions. This is particularly true for the use case of disabled persons, posing new constraints in the SRA that have to be taken into account when solving the query.

To have a broader view of the user, the UC block alone is not enough. This is due to the fact that the UC only accumulate static information, and does not take into account the specific situation the user is involved in. This is the role of the Context Awareness block, which considers the context in which the query has been made. For example, a tourist with a certain disability looking for a museum to visit, can receive different recommendations based on the accessibility of the structure, the time of day, the possible routes to reach it, the presence of uphills and downhills, the distance from other museums or the number of people in the queue waiting to visit it.

Finally, since an application is composed of one or more services, there is the need of a Decomposer, which collect the information obtained by the other blocks in this layer and decide which atomic tasks (sensing, actuation, computational) are needed to fulfill the query. Then, it forward a group of subqueries for the Virtualization Layer.

1. (3) Virtualization Layer: This layer is responsible for virtualizing the sensor (& actuation) data for any service needs, which is stored in a related database. Objects and devices of the real world are represented digitally in this level in the form of Virtual Objects (VOs) and their offered services are described in terms of semantics.

To overcome the limited capabilities of the IoT objects, in the virtual world the VOs enhance their capabilities and enable them to perform additional operations. White canes, i.e. canes for blind or visually impaired people, wheelchair but also museums, parks or busses can communicate among them without any problem at this level even if they all use different communication technologies: simple technologies, such as RFID tags and NFC, can be attached to Points of Interest (PoIs) to enhance the visiting experience of tourists by interpreting information about the environment and making choices accordingly, for example by pushing additional information regarding the PoI to users [26].

To activate a new VO, the system has to find a match between the possible VO templates and the information (metadata) provided by the physical device; such information comprehends: objects’ characteristics; objects’ location; resources, services, and quality parameters provided by objects. When a match is found, a new instance of the object is created (i.e. the web server representing the VO itself), which run in the Virtual Object Execution Space (VOES), where all the instances of VOs run.

Each VO has two interfaces: the first one enables the VO to create a standardized communication procedure with the physical object; this way, the VO can communicate with the object using a set of different protocols based on the situation at hand. The other interface allows the VO to “speak” with all the other VOs in the VOES; thank to this, it is possible even for physical objects with have different communication technologies to communicate among them and become interoperable at the virtual level.

The VO registry stores a semantic description for each active VOs in the VOES, in the form of metadata, which is then used every time there is the need to search for a particular VO.

This metadata is particularly useful in the case of accessible tourism, where the information regarding the different objects available for people with disability needs to be described with the correct metadata in order to be easily discoverable; this is the case for example of busses with a platform for tourists in a wheelchair or of museums which provide audio guides for visually impaired tourists.

When the Search and Discovery Engine is activated by the upper layers, it search in the VO registry to find any potential available VO that can match the query, i.e. any VO whose metadata can match the services required.

1. (4) Real-World Object Layer: Implemented out of the cloud, this level includes every device that is capable of accessing the Internet. These devices are called Real World Objects (RWOs) due to their direct connection with the physical environment where they sense and act.

2. (5) Trust and Security Engine: This layer focuses on the implementation of appropriate security procedures to guarantee that attacks and malfunctions in the platform will not outweigh any of its benefits. At the Virtualization level, for example, this plane needs to understand how the information provided by the VOs have to be processed so as to build a reliable system on the basis of their behavior. In the Application level, the Security Engine could determine the accessibility of the different applications to grant access only to authorized users.

3. (6) QoE/QoS Manager: The management of quality is an important issue in classical IoT implementation mainly due to the heterogeneity of the objects and to their mobility. In the proposed platform, we address these problems making use of VOs; however, even with the adoption of virtual counterparts, in order to monitor the overall level of the applications, both from a communication point of view (Quality of Service) and from a user point of view (Quality of Experience), a quality manager is still needed.

5.1. Cruise tourism

When arriving in Cagliari, many cruise ship tourists, often prefer to take a walking tour rather than taking an organized tour. After getting off the cruise ship, these people have to spend too much time to get the needed information about programming their visit. And time is a very critical aspect for cruise ship tourists, due to the limited number of hours the cruise ship usually stays at the call port. This aspect gets worse for disabled people, depending on the type and degree of disability. In the case of mobility disability, for instance, a destination like Cagliari, where reaching the most important attractions require a lot of walking uphill, due to the natural and geographical features of the city, many tourists are constrained to limit their visit to the areas around the port. Instead, with some detailed information about accessible routes in the city, more tourists could reach all the attractions of interest within walking distance of the port getting a better experience from their visit. This is why we designed and developed a mobile application dedicated to generic tourists and specifically adapted to accessible tourism. In case of physical impairments, this mobile application is capable to optimize visits to specific mobility user needs. In this work we adopt the paradigm of people inclusion and universal access to information and tourism assets.

In the recent years, tourism experiences of people with disabilities have largely been a research key topic [27]. Research results have been focused on accessible tourism and accommodation preferences [5]. Most of the available tools are based on web sites for travel planning with focus on inclusive tourism such as Tur4All (https://www.tur4all.com/) andJaccede.com(https://www.jaccede.com/). Specific tools face just single aspects of the problem. LinkedQR [28] is a tool to improve the collaboration between QR codes and Linked Data, through mobile and Web technologies. Nevertheless, the role of IoT in tourism is expected to create innovative experiences for consumers [29].

There is a lack of tools specifically designed for everyone and able to perform specific outcomes for disabled. Our application addresses this challenge, following the paradigm of whole-of-life to tourism, considering that 30% of a population will have access requirements at some stage during their life [4].

5.2. The tour planner application

The Tour Planner is a mobile application, useful to build a dynamic itinerary through a city, based on a repository of Points of Interest (PoIs), each one of them is represented as a VO on the platform (Figure 2).

The Tour Planner application is developed on top of the proposed platform, and it takes in input not only the Points of Interest related to monuments, museums, archeological sites, parks, botanical gardens, shopping areas, restaurants, but also commercial offers and events as well as every information that can be important for the user, such as his/her particular needs, the length of the queue in real time from the PoIs or the weather.

Moreover, the Tour Planner allows to save the itineraries built by the end users (the tourists) in a format suitable to be saved in the platform, then making it available for other users. The information available on the platform are regularly taken and stored (updated) in the back end of the mobile application. The mobile application has been developed with the Ionic Framework in order to be suitable for any mobile platform.

The platform takes all the information about the Points of Interest (PoI) in a certain geographical area. The PoIs are stored in the platform according to a classification related to the type (the already mentioned, monument, museum, archeological site, etc.).

5.3. How the tour planner works?

The Tour Planner aims to improve accessible tourism because it provides the possibility to build itineraries suitable for people with disability, adding detailed information about the accessibility of each Point of Interest, whenever available. Unfortunately, a well-known problem is related to the fact that most of the web sites based on the Points of Interest paradigm do not follow standards like the “ISO 7001:2007 Graphical Symbols” (https://www.iso.org/obp/ui/#search/grs/7001). Although not comprehensive, these standards are suitable to notify tourists about the existence of facilities for disabled people. The information would be complete if also the “not existence” of the facilities would be reported (in a standard way, as well). Another issue in relation to this aspect is that quite often the presence of these facilities is not compliant to standard like the ISO 21542:2011 for building construction - Accessibility and usability of the built environment (https://www.iso.org/obp/ui/#iso:std:50498:en).

Some disability rights organizations periodically (for instance, yearly) verify if declared accessibilities are compliant to the standard. As a good example of this, in UK, there are important providers of access information like DisabledGo (https://www.disabledgo.com/). If this kind of verified information could be automatically collected and stored in the platform, the Tour Planner application would be able to acquire them and to build proper itineraries accordingly. In our case, a further improvement should come from the municipality of Cagliari by providing access infrastructures through the streets of the historical city, and making the related information available.

In this accessible destination scenario, a disabled person, for example with a limited degree of mobility, could use the Tour Planner application to properly construct his or her tour, including the PoIs and the routes that connect them, depending on the needed level of accessibility.

Obviously, the presented Tour Planner application represents only a technology which allows this scenario of accessible destination to become reality; in fact, the solution requires some effort by the decision makers in order to make all the actors of the scenario to co-operate for realizing it (Figures 3 and 4).

The aim of the Tour Planner application is to make the visit of a destination accessible for everyone, addressing the described critical aspects through the following features:

1. The tourist defines the total amount of time he has to visit, his physical training level with respect to available paths, and the type of preferred attractions.

2. The application shows a list of most important Points of Interest, sorted according to the information described in 1.

3. The tourist can select each Point of Interest to get more information, including those related to accessibility, and then has the possibility to choose what to see during the visit.

4. The application connects the Points of Interest selected and optimizes the resulting path producing a tour suitable to the tourist.

6.1. First model

We consider the current location 0 of the tourist and a set I of POIs. A time interval d can be spent at most to visit a number POIs from the current location. Each POI is associated with a ranking pi representing its attractiveness for tourists and a visiting time vi.

The problem can be described as the following graph theoretic problem. Let GNAbe a direct and complete graph, where N is the node set and A the set of arcs connecting nodes of set N. Nodes correspond to the points of interest and the current position of the tourist, i.e., N=I∪0. Arcs represent possible connections between two distinct nodes. Let ti,jbe the time to move along arc ij∈Aand M a large positive constant.

The following decision variables are defined:

• Xi,j∈01is equal to 1 if the tourist moves along arc ij∈A, 0 otherwise;

• Yi∈01is equal to 1 if POI i∈Iis selected for the visit, 0 otherwise;

• Ui∈0…Nis the position of POI i∈Nin the current trip.

The problem can be formulated as follows:

In (Eq. (1)) one maximizes the ranking generated by the selected POIs. According to (Eq. (2)), a PoI must be visited after the current location. Constraints (Eq. (3)) enforce for the tourist to come back to the current location after the visit of the last PoI. Constraints (Eq. (4)) guarantee that a tourists arriving at any PoI must also leave from that PoI. Constrains (Eq. (5)) link decisions variables on POIs selections and movement between nodes. Constraints (Eq. (6)) are the subtour elimination constraints of Miller, Tucker, and Zemlin. Constraints (Eq. (7)) enforce that the overall time spent to move between nodes and visit POIs is lower that the planned time interval. Finally, (Eq. (8)), (Eq. (9)), and (Eq. (10)) are the domain of decision variables.

It is worth noting that one does not have to visit all nodes of the N, unless a large value of d is considered. Moreover, the direct graph makes very easy to model the case in which starting and arrival points are different.

6.2. Second model

Consider the subset N¯of nodes selected in the previous model. These nodes may not be visited in an effective order, as this model does not aim to minimize the costs of movement between nodes. To correct this drawback, we consider a second model, in which a formulation of the Traveling Salesman Problem (TSP) is presented. The solution of the TSP determined the so-called optimized itineraries mentioned throughout this paper.

The TSP can be described as the following graph theoretic problem. Let GN¯A¯be a direct and complete graph, where A¯the set of arcs connecting nodes of set N¯. The following decision variables are defined:

• Xi,j∈01is equal to 1 if the tourist moves along arc ij∈A¯, 0 otherwise;

• Ui∈0…N¯is the position of POI i∈N¯in the current trip.

The problem can be formulated as follows:

In (Eq. (11)) one maximizes the ranking generated by the selected POIs. According to (Eq. (12)) and (Eq. (13)), a node must be visited before and after the current one, respectively. Constraints in (Eq. (14)) are the subtour elimination constraints of Miller, Tucker, and Zemlin. Finally, (Eq. (15)) and (Eq. (16)) are the domain of decision variables.