Abstract
This work presents an architecture to help designing and deploying smart mobility applications. The proposed solution builds on the experience already matured by the authors in different fields: crowdsourcing and sensing done by users to gather data related to urban barriers and facilities, computation of personalized paths for users with special needs, and integration of open data provided by bus companies to identify the actual accessibility features and estimate the real arrival time of vehicles at stops. In terms of functionality, the first “monolithic” prototype fulfilled the goal of composing the aforementioned pieces of information to support citizens with reduced mobility (users with disabilities and/or elderly people) in their urban movements. In this paper, we describe a service-oriented architecture that exploits the microservices orchestration paradigm to enable the creation of new services and to make the management of the various data sources easier and more effective. The proposed platform exposes standardized interfaces to access data, implements common services to manage metadata associated with them, such as trustworthiness and provenance, and provides an orchestration language to create complex services, naturally mapping their internal workflow to code. The manuscript demonstrates the effectiveness of the approach by means of some case studies.
1. Introduction
As world populations concentrate in cities, mobility in urban environments is becoming one of the most prominent and interesting research fields in the smart city context. A well-known definition of smart city is provided in [1] and says that a smart city is “a city well performing in a forward-looking way in economy, people, governance, mobility, environment, and living, built on the smart combination of endowments and activities of self-decisive, independent and aware citizens.” The World Health Organization has recently released a report about Urban health [2], which claims that about 3.7 billion people live in cities today and that a further 1 billion people will be added by 2030, with 90% of the growth being in low- and middle-income countries. According to this study, the ways that cities are planned and built can profoundly affect the ability of their citizens to live long, healthy, and productive lives. Urban mobility plays a key-role in this context, because it is strategic in making cities age-friendly and accessible for communities, with particular regard to those persons with disabilities [2]. Hence, providing and adequately orchestrating services devoted to improving urban mobility is fundamental in achieving smart mobility [3].
In this context, the crowdsensing and the mobility as service paradigms are emerging. In particular, crowdsensing is rising thanks to the widespread diffusion of mobile devices: it involves people who are moving and collecting data from different places and routes, by carrying sensors integrated in their mobile devices, such as smartphones and tablets [4]. Here, we can identify the three interrelated components (space, people, and technology) of the urban computing systems, as presented in [5].
The concept of Mobility as a Service (MaaS) was born in Finland and it is rapidly spreading worldwide [6] as an effective approach to achieve business efficiency, traveler satisfaction, and government agenda fulfillment through smart mobility.
Given this background, we envision the creation of ICT infrastructures based on microservices. This modern and renowned development model [7] fosters the creation of an ecosystem of reusable components. In the context of MaaS, microservices shall efficiently and flexibly combine heterogeneous data sources, such as available transport options, real-time data regarding vehicles and infrastructures, and pricing, to provide customized travel planning, information, and ticketing to final users, as well as monitoring and strategic planning tools to policy-makers. In this context, crowdsensing plays a fundamental role, letting the users and their devices be a significant actor in the whole picture, becoming one of the data sources. As emerging by the results found in [8], crowdsensing from citizens’ devices is an important advantage and opens a range of potential applications and tools. This would improve data and applications made available by operators, policy-makers, and transport providers, enriching the entire smart mobility context.
This paper presents the design of an infrastructure as a marketplace for mobility services, called Smart Mobility for All (SMAll). A prototype of such infrastructure has been developed and its architecture is described in the remainder of this paper, as well as some of the provided services. In our vision, SMAll is the enabling technology to solve the challenges of the MaaS market, from developing user-contributed, crowdsourced applications and crowdsensing services to launching a MaaS operator and to planning effective and sustainable transport policies for smart cities. Particular attention has been given to specific services offered with the aim of supporting mobility of citizens with disabilities and special needs within urban environments.
The remainder of this paper is organized as follows. Section 2 presents the background and some of the main related work which have inspired and driven our research. Section 3 describes the overall system architecture we have designed and developed, which is based on services orchestration. Two broad categories of services, namely, data quality management and data sources, are illustrated in detail in Sections 4 and 5, respectively, before their orchestration is described in Section 6. Two case studies are introduced in Section 7, and, finally, Section 8 concludes the paper and presents some future works.
2. Background and Related Work
An emerging trend introduced with cloud computing [9] defines a new category of models which can be identified under the umbrella term Everything as a Service (XaaS) [10]. The basic idea behind cloud computing is to concentrate resources, such as hardware and software, into few physical locations and offer those resources as services to a large number of users who are located in many different geographical locations around the world in an effective way. In this context, three major service models have been traditionally exploited: infrastructure-as-a-service, platform-as-a-service, and software-as-a-service. The main common element among them is that they all provide resources as a service. These models arose a wide popularity and starting from them, several similar yet context-specific models have been proposed [11].
One of these ones is the Sensing as a Service (SaaS) model, which can be considered a solution based on IoT infrastructure and it has the capability to address some of the most challenging issues in smart cities [12]. Many everyday objects are equipped with sensors and the European Commission has predicted that, by 2020, there will be 50 to 100 billion devices connected to the Internet [13]. This represents a strong motivation behind the diffusion and the opportunity of efficiently exploiting the SaaS model. In a typical SaaS cloud, multiple sensing servers can be deployed to handle sensing requests from different locations [14]. Usually, a SaaS cloud works as follows. When a cloud user initiates sensing requests through a Web front-end from either mobile phone or a computer, the request will be forwarded to a sensing server which will then push the request to a subset of mobile phones that happen to be in the area of interest [15]. Such mobile devices will fulfill the corresponding sensing task. The sensed data will then be collected by a sensing server, stored in a database and returned to the cloud user who requests the service. An interesting feature is that in such a system a mobile user can be at the same time a provider and a consumer of the sensing services [15, 16]. And this is the case of the sensing service prototype we are going to present in Section 4.2 of this paper.
Taking into account mobile phone sensing, we can identify two primary paradigms [17]:(1)Participatory sensing: mobile users actively engage in sensing activities by manually determining how, when, what, and where to sense.(2)Opportunistic sensing: sensing activities are fully automated without the involvement of mobile users.
It is worth mentioning that, despite the fact that in traditional sensor network the owner is typically a single organization, in mobile phone and sensors the control is spread between different individual users. This means that mobile sensing activities and resulting data are not controllable and not easy to predict [14]. In some contexts, in particular in the participatory sensing ones, SaaS is considered as a crowdsourcing system that depends on mobile users to provide data [15], and it can also be referred to as crowdsensing [18], which has been also defined as a subtype of crowdsourcing, where the outsourced job is a sensing task [4].
Crowdsensing is recognized as an important technological enabler for smart cities that has attracted several research efforts, with the aim of improving sensing quality on mobile devices, promoting user participation, and validating collected data [19, 20]. Compared to infrastructure-based sensing, crowdsensing has several advantages, even if it can bring some additional issues.
A system based on crowdsensing can potentially be cheaper than infrastructure-based sensing solutions, because it does not require the deployment of expensive fixed infrastructure. Moreover, it is easier to deploy and can be used in areas where deploying a fixed infrastructure can be difficult or maybe impossible, but it can introduce additional complexity and challenges. In general, mobile devices used for crowdsensing and infrastructure-based sensing are complementary technology that can cooperate to enable sensing in smart cities [18].
In the smart city context, crowdsensing can be exploited by involving sensors which are moving (since they are carried by users) and human intelligence into the sensing process [4]. Some of these use cases address tasks related to urban transportation systems, such as tracking of public vehicles (e.g., buses, trams, and subways) or others like mapping bumps on the road to inform authorities.
Crowdsensing can provide great support in optimizing urban transportation. Traffic can be unpredictable; moreover, most influenced public transportation lines can bear shorter or longer delays. Weather conditions can influence the traveling speed of vehicles in the city. In [21], an effective way of describing the entities of a crowdsourced public transit networks (including locations and vehicles) was presented and discussed. A system devoted to monitoring public transport vehicles with an application running on traveling users’ mobile phones and detecting the stopping places of vehicles is described in [22]. An interesting example of participatory sensing is represented by the platform called Waze [23], which supports car drivers to get information on road conditions. Thanks to its versatility, it was the wider community-assisted navigation app in 2015. To improve routing, users can report changes in local maps to keep them up to date [4].
It is important to note that systems based on crowdsensing need to reach a critical mass of gathered data in effectively and efficiently providing services. For this reason, contributors have to feel motivated and involved in collecting data. Different research works have proved that resorting in intrinsic motivation (the activity is perceived as intrinsically rewarding) and/or extrinsic motivation (the action is driven by an external outcome, as rewards or an increase of reputation) makes it possible to engage contributors in participating, with an increment of the quantity and quality of collected data [24, 25]. An interesting concept that some of the authors are investigating is the one about the use of gamification so as to motivate the participation of the crowd in gathering data about the urban environment (see, e.g., [26–28]).
Some among the several crowdsourcing and crowdsensing systems and applications developed in the smart cities paradigm are devoted to let citizens collaborate in improving the quality of life in their urban environment [29, 30]. A part of them aims to collect data about urban accessibility [31], improving the quality of life and the level of independence of persons with disabilities [32, 33]. Many sensing apps have been developed to monitor human activities and a part of them could be effectively used to detect accessibility/pedestrian barriers (such as stairs) and facilities (such as zebra crossing). These researches present sensing architectures and algorithms studied to be used in different contexts, so they need to be adapted in order to be exploited in detecting barriers and facilities (see, e.g., [34, 35]). In [36], the authors (by using data obtained by a smartphone accelerometer) aim to recognize the position where a pedestrian stops and crosses a street ruled by a traffic light. Some barriers and facilities could be recognized more easily by using cooperative sensing, working on detecting movement of groups of people [37]. In [38, 39], the authors propose methodologies for developing large scale accessibility map with personal sensing by using smart phones. In particular, the idea is to exploit devices held by wheelchair citizens and then to apply machine learning technologies (i.e., supervised learning techniques) with the aim of estimating types of ground surfaces.
Using moving sensors in crowdsourcing is called mobile crowdsensing (MCS) [4]. MCS differs from the deployed sensor networks in involving people who are moving and collecting data from different places and paths. People can carry sensors integrated to their mobile devices and they can provide information about the surroundings manually [19]. The MCS as a Service (MCSaaS) paradigm has been proposed in [40]. The authors discussed about the MCSaaS vision and presented a platform prototype and its evaluation. In particular, regarding the MCSaaS vision, the authors proposed to implement such an approach by splitting the MCS application deployment into two domains: the infrastructure and the application ones.
Another important and interesting concept that is at the basis of our work is Mobility as a Service (MaaS) [6]. One of the main advantages of a MaaS provider is that it shall offer a unique and seamless interface to users, aggregating heterogeneous transport options offered by different mobility providers (e.g., different agencies providing transportation by taxi, bus, train, airplane, and car-sharing, including the public transportation providers) and handling the whole experience of traveling, from providing information to travel planning and payments [41].
All these concepts and studies have inspired our work and the resulting system we present in this paper. In particular, our prototype is exploiting sensing, mobile crowdsourcing, and mobility as a service with the specific purpose of supporting citizens in wandering the city (i.e., in the context of smart mobility). A specific attention has been paid to meet the needs of those people who would get more benefits than the others from the availability of information about urban accessibility in terms of barriers and facilities.
3. Smart Mobility for All (SMAll)
From a software engineering point of view, it is useful to frame the various functions needed to build any smart-city vertical application within a common reference model based on microservices [7].
By modeling and implementing every component of a mobility application as a service, several remarkable advantages emerge. Data can be transparently collected from different sources that, wrapped inside a microservice, become available through a standard interface. Preprocessing and labeling of data, for example, to assign trustworthiness values, can be implemented by means of different algorithms available as services; these, in turn, can take advantage of shared knowledge bases, for example, managing user ratings. Sharing databases through services instead of giving direct access means having a finer control on access policies, both in terms of simple access rights and in terms of precomputations that allow providing properly aggregated or otherwise sanitized data to applications. It is worth noting that security issues can emerge from this kind of open structure, yet the platform itself can play a crucial role in mitigating them [41, 42].
Generally speaking, a platform to “glue” mobility services together could enable the establishment of Mobility as a Service operators.
One way to develop a MaaS-enabling infrastructure is to structure it as a marketplace (Figure 1) for mobility services, where the definition of open standards for service invocation guarantees interoperability, the availability of infrastructural components (i.e., authentication, access control, QoS negotiation, and business intelligence) lowers the effort needed for the development of applications, and an orchestration framework streamlines the composition of available services into more complex applications. We are developing a prototype of this system called SMAll.
Indeed, we already classified some macrocategories of services that we can expect to find in such a marketplace. Figure 2 outlines some of the most important ones, arranged in layers of increasing complexity—in this context, “complex” means the creation of functionalities on top of other “simple” services. Starting from the bottom, we find services that are either wrappers for legacy software, for example, travel planners that do not include real-time functionalities, or services that process basic data. The aim of this class of services is to standardize the data and the interfaces of legacy software to make them available to other services. Other more complex services, found in the upper layers, orchestrate these basic ones to implement their behaviors, up to the very refined policies of MaaS operators and similar applications.
As mentioned at the beginning of the section, we envisage the adoption of microservices to provide seamless implementation of these categories of components:(i)Wrappers converting legacy data source into standard services(ii)Helper services (e.g., authentication, authorization, scheduling, routing, and orchestration)(iii)The service registry storing the definition of all the services deployed on the platform(iv)The actual business logic deployed by operators or intermediaries, collecting, storing, and processing data to offer some data-related insight on the usage of services.
According to this model, there is no single actor responsible for data quality and service correctness, so we are introducing a layer of services to manage the quality issues of data resulting from crowdsourcing. This layer will offer metadata management services, such as the evaluation of data provenance, data reliability, and data trustworthiness, and the propagation of these indicators across services which compose data, ready to be exploited in coordination with any service that exposes data. The microservices architecture is suitable for this kind of scenario, because it allows creating independent services for specific tasks (and for different implementation of the same task) of the data quality management process. On the SMAll platform, it will be possible to exploit these services through orchestration.
The concept is illustrated in Figure 3.
On the bottom level, we have the services that expose data. These services are heterogeneous in terms of amount, sensitivity, expressiveness, representativeness, and so forth. Above the data level, there are the microservices in charge of the implementation of the mechanisms dealing with each of the data management problems described (provenance, trustworthiness, etc.). While the two levels are kept separated to highlight their different function, there is no hierarchical relation between them. From an architectural point of view, every box is a service, and their invocation is defined by a workflow, representing the desired data quality policies, and implemented through the orchestration mechanism.
4. Data Sources
Various kinds of data sources feed the system. We can classify them in broad categories, according to their provenance (e.g., official data about the transport infrastructure versus crowdsourced POIs) and their timescale (e.g., real-time information versus planned timetables and static features). Indeed, each stored data includes specific information and has peculiar characteristics depending on its own source. For instance, traffic data feeds are automatically posted and updated in the system; instead, the quantity and quality of crowdsourced/crowdsensed data are strongly influenced by the voluntary nature of the action and engagement of the participant [43].
In any case, all the data sources, independently of their category, will be accessed in a homogeneous fashion, through appropriate microservices.
4.1. Profiling System
To provide personalized services, we have to build a category of services that exploits a user (JSON-based) profile, structured in three interconnected parts: (A) the Generic Profile (GProfile) which includes some general data about the user, such as personal info, language, unit of measurement, device(s) in use, average walking speed, data about his/her credibility, and data about his/her favorite public means of transport routes; (B) the Urban Profile (UProfile), which describes users preferences related to the urban environment, expressed according to his/her needs, and preferences about the urban Point of Interests (POI); a specific section of such a part of the profile is devoted to describing the user’s preferences about the urban barriers (such as stairs) and facilities (such as curb cuts); and (C) the eAccessibility Profile (eAProfile), which describes users preferences related to the e-accessibility and to the interface of the application.
4.1.1. Generic Profile
The Generic Profile describes the general information about the user. It includes personal data and data about the device in use, as well as the language and the unit of measurement. These latter data can be automatically set by the service, deriving them from users location, or manually set up by the user. In such part of the profile, the user can also declare his/her average speed when he/she moves in an urban environment. Alternatively, such data can be automatically derived from device sensor, which can track the users movement and then compute his/her average speed. This information is essential for our system, because the routing algorithms compute the best personalized paths taking them into account. For example, when combined to real time availability of buses (when the paths include the use of public means of transports), the user’s ability to reach a stop in time to catch the bus prunes the set of feasible different paths. Finally, the user could store here information about his/her traveling habits, providing data about his/her favorite bus routes. The user can provide a location in the city by exploiting his/her current position or an address (i.e., street and number). Then, our system provides all the bus stops that the user can reach (in a configured time) with a list of the bus routes available at those stops; finally, the user can choose bus stops and routes of interest.
4.1.2. Urban Profile
The Urban Profile stores information about users preferences related to the urban environment. In particular, the urban elements are called Point of Interests (POIs) and users can set their preferences, classifying them as NEUTRAL, LIKE, UNLIKE, and AVOID on the basic of their degree of interest, preference, and/or need. Some examples of POIs mapped in our system are bus stops; subway stations; bicycle-sharing stations; parking; and so on. An interesting subset of POIs is related to identify urban barriers and facilities in the city. Such specific POIs are defined as aPOIs (accessibility Points of Interests). We have classified the aPOIs in categories that derive from the mobility context, in particular for those people with disabilities that we treat in the use cases of this work (see Section 7). These categories include items such as gaps, crosses, obstructions, and surface descriptions. Users have the possibility of defining their preferences about the above-listed aPOIs (stored in the Urban Accessibility Profile (UAProfile)) as follows:(i)NEUTRAL: the user has neither difficulties nor preferences related to the aPOI type. The presence of this type of barrier/facility on a path is irrelevant to the user.(ii)LIKE: the user prefers aPOIs of this type, when they are available. The presence of this type of barrier/facility on a path is positive to the user.(iii)DISLIKE: the user can face this aPOI type, but with some efforts. In this case, an alternative path is preferred (when available), but it is not necessary. The presence of this type of barrier facility on a path is negative to the user.(iv)AVOID: the user cannot face this aPOI type and an alternative path is necessary. The presence of this type of barrier/facility on a path prevents the user from following this path.
A more detailed description of such urban accessibility preferences can be found in [33, 44]. On the basis of them, our system computes an accessible route that comes across the LIKEd aPOIs when feasible, gets round the DISLIKE aPOIs if it is possible, and avoids the AVOIDed aPOIs every time. It is worth noting that positive preferences can be associated with barriers and negative preferences can be associated with facilities. As an example, a blind user can set as LIKE some specific barriers, such as stairs and steps, because they can represent a reference point. Analogously, wheelchair users can set tactile paving as DISLIKE, because such surfaces can be uncomfortable for them.
4.1.3. eAccessibility Profile
The e-Accessibility Profile is devoted to storing preferences and needs in terms of maps rendering. The main selection is the one related to textual/graphical representation of the map. On the basis of it, users can choose specific styles to represent POIs. For instance, the graphical representation can be personalized in terms of colors and size of the POIs icons in the map, addition of textual labels, and visualization (show or hide) of POI categories or of POI types. In particular, different style rules can be associated with the whole application, to a specific preference (LIKE, DISLIKE, etc.) or to a single type of POI.
4.2. Data Sensing
We designed and developed a specific sensing service prototype that would be exploited on users smartphones, with the aim of sensing stairs, automatically storing information about such a kind of urban barrier. Stairs are commonly placed in pedestrian areas of the urban environment, in particular in European cities, due to their old origins. As an example, we report in Figure 4 a picture taken in Bologna. Bologna is famous for its porticos, which are devoted to pedestrian paths all over the city (over 45 kilometers of arcades) and where stairs often affect the urban accessibility.
The design issues of such an ad hoc service were based on the need of low energy consumption and of high precision, minimizing false positive and false negative results. Analyzing the sensors available on a smart phone, we focused on gyroscopes, accelerometers, and magnetometers. The idea was to create a service, which would be used in background, without affecting other uses activities, applying an opportunistic sensing.
Several methodologies have been evaluated, such as sensors fusion (combining data coming from the gyroscope, the accelerometers, and the magnetometer, with the aim of identifying the device inclination), Fourier analysis, Kalman filtering, convolution (cross-correlation and signal analysis of the forces applied on the device, with the aim of reconstructing and interpreting the device movements). We have exploited this latter method, by using only the accelerometer. In particular, our prototype compares the signal recorded by the smartphone accelerometer with a set of presampled ones, so as to assess the actual presence of a stair. Such presampled signals correspond to signals obtained climbing stairs up and down, by a group of different users equipped with their smartphones in different modalities (by walking, by running, and by keeping the smartphone in the pocket, in hand, in a bag, or in a backpack). The use of this method (and in particular of the sole accelerometer) lets us avoid the use of the gyroscope, then limiting the energy consumption and false positives and negatives.
The sensing prototype we have developed is based on Android operating systems; it exploits the spatial components thanks to the accelerometer, which senses the force applied to all spatial components. Once our sensing service prototype recognizes the presence of a stair, data about its position are sensed and stored. Hence, our prototype records the sensed data, analyses them, and stores the corresponding signal. A screenshot of a corresponding plot is shown in Figure 5.
4.3. Transit Infrastructure
Information regarding the operation of buses, trains, and other means of transport is possibly the most complete example of variety that benefits from the standardization offered by wrapper services.(i)Operators are usually the authoritative source for static information about the transport infrastructure (stops, routes, etc.) and planned services (timetables, vehicles features, etc.). Operators can make this data available through different open data formats. GTFS [45] is rapidly growing to the status of de facto standard, yet many company-specific formats are still in use. A set of wrapper services is useful not only to convert these formats into a standard one but also to offer more sensible ways to access data, for example, allowing for discovering nearby stops given an address or set of coordinates, to know the set of bus lines serving a given stop, and so forth.(ii)Real-time information about the transport services is, again, usually provided by operators. Depending on the end-user needs, it could be useful to know either the position of a vehicle or its delay with respect to planned operation or the estimated time of arrival at a given stop. Of course, these data are all mutually related, and it turns out that different operators may decide to provide different views of the same basic information (in our region, e.g., the biggest bus operator provides the arrival time of the next two buses at a given stop to the public, but at the same time, it feeds the “raw” GPS position of each vehicle to the regional transport authority, which is considering to make these data available for crowdsourced applications). By wrapping the composition between the available kind(s) of data and other information (e.g., position of vehicles crowdsensed by passengers, travel times measured on street segments), it is possible to obtain all the needed views and even to improve the precision of estimates.(iii)Real-time information about the transport infrastructure comes from many different sources, such as public administrations announcing planned or extraordinary works, emergency teams intervening on accidents, operators giving notice of strikes of vehicle failures, weather reports, and of course people in the streets.
5. Data Quality Management Services
Various kinds of data sources feed the system. We can classify them in broad categories, according to their provenance (e.g., official data about the transport infrastructures versus crowdsourced POIs) and their timescale (e.g., real-time information versus planned timetables and static features).
Indeed, each stored data includes specific information and has peculiar characteristics depending on its own source. For instance, traffic data feeds are automatically posted and updated in the system; instead, the quantity and quality of crowdsourced/crowdsensed data are strongly influenced by the voluntary nature of the action and engagement of the participant [43].
In any case, all the data sources, independently of their category, will be accessed in a homogeneous fashion, through appropriate microservices.
5.1. Data Provenance
Data Provenance for single hosts sources is a known problem in literature. According to works like [46], this problem could be solved only with a creation of private and public key system for data stream certification. A good reference is the system developed in [47], describing a cryptographic provenance verification approach for ensuring data properties and integrity for single hosts. Specifically, the authors designed and implemented an efficient cryptographic protocol that enforces keystroke integrity. This kind of protocol can be integrated as a microservice in our architecture. However, public-key schemes are known for their significant computational load, thus existing techniques may not be suitable for high-rate, high-volume data sources. Moreover, there could be the need for an algorithm for the propagation of provenance data. In some cases, data originated from the composition of raw (or otherwise “lower ranked”) sources should be accompanied by suitable metadata that allows verifying the provenance of the input values, in a cryptographically strong way. Merkle hash trees could be a good candidate to build proofs for composed data pieces [48].
5.2. Data Trustworthiness
Trustworthiness often referred to measuring and quantifying the quality of information coming from online resources and systems [49]. Several studies have been conducted with the aim of supporting users in quickly judging the trustworthiness of information they get, providing automatically computed values, which can be continuously updated [49, 50]. The authors of [51] based the trustworthiness model on users mobility and on the usefulness of their past contributions to the system. This work focuses on data integrity (for data coming from automatic readings from devices), data correctness, and quality. Users contributions are compared with those ones provided by local authoritative data sources, certified by the data provenance microservice. The trustworthiness microservice considers information provided by authoritative data sources (i.e., local administrations, municipalities) as a gold set. Thus, our idea is to compare information provided by users with trustworthy and correct data. Hence, it is possible to base our trustworthiness service on the computation and assignment of more effective credibility values to users, similar to what has been done in other works, for example, [52].
5.3. Data Reliability and Reporting Service
Once we are able to verify the provenance and trustworthiness of the data intended as verification of the correct elaboration process, we have to verify that the results or the data displayed are actually correct. The process of correctness verification of the results of a crowdsourced data can be done in two ways: through an automated system with artificial intelligence embedded or through a reporting system with a trusted source approach. Considering that this work is mainly aimed at helping disabled people, who are known to be more collaborative in using reporting systems, has obviously led us to implement the second solution. The description of the reporting system for our architecture is inspired from the mPASS model [32], which is based on the mapping of POI. Each POI and its related data can be added to our system by means of one or more reports. Reports are classified in three different source classes, according to how they are collected. The three source classes have a growing validity:(i)U-report (report obtained by users): users can add POI to the DB system. This can be done in two ways: (i) spontaneously, a user encountering a specific barrier or an accessibility facility can send a report to the reporting service (RS); (ii) on demand, the RS can ask users to improve validity of an existing POI (usually a POI reported by sensors). Hence, the system will exploit the user report instead of sensor ones and the user gets an award badge on his/her public profile.(ii)S-report (report obtained by sensors): the RS can automatically produce data by sensing from mobile devices sensors. These reports are supposed to have a low validity.(iii)E-report (report produced by experts): experts are people working for organizations involved in monitoring urban accessibility (such as local administrations and municipalities or disability right organizations).
Being professionally able to correctly classify and measure every kind of POI and POIs, their reports are considered totally valid. Reports from administrators can be added in two ways: (i) spontaneously: administrators add reports according to their program of activities, sending to the RS reports on barriers or accessibility facilities; (ii) on demand: the RS can ask administrators to improve validity of an existing POI (usually a user-added one). Hence, the system will use the administrator report instead of user ones. Hence, the RS can have more reports of the same POI, classified with one or more different source classes. Both the map provided to users and the data set considered by the routing algorithm are based on the more valid reports available. For example, if a POI is added by both sensors and users, U-reports are used instead of S-reports, since they are considered more valid. Analogously, if a POI is added by both users and administrators, E-reports are used instead of U-reports, because they are considered more valid. To populate the RS database, we also added some POIs and reports obtained by converting, filtering, and mashing up existing data.
5.4. Feedback Scoring System
The Feedback Scoring System service is linked with the reporting service, an algorithm that calculates the reliability of a report based on the assigned scores on the basis of certain characteristics. It can happen, however, that in some cases these reports are uncertain, or missing, or simply they are too few to yield a reliable result. In this case, we can ask for the user interaction in order to give a feedback of a specific case. When uncertainty occurs on a POI, we activate a simple mechanism of user request, asking to confirm the presence/absence of this POI or to confirm parameters about measures of this POI. This feedback cannot always be sharp; it can include a confidence score, showing how much the user trusts the POI features to be correct. This score will be used to recalculate the reliability of the crowdsourced data.
6. Orchestration
The core of this architecture is the orchestration process. As previously described, as service orchestration we mean the composition of microservices, tools, and processes invoked and the connection and automation of workflows to deliver a defined service [53]. To this end, our platform can natively run orchestration tasks written in Jolie [54], a programming language offering several structural advantages: it provides workflow constructs such as sequence, parallelism, and nondeterministic choice for composing communication interactions, it deals with statefulness by activating different workflow instances for each business task to manage, and it implements interfaces to almost every communication protocol commonly used.
Figure 6 represents one of the possible workflows managed by the orchestrator. The idea is that the evaluation of data quality is carried out by suitably combining one or more specific microservices.
In our case, the workflow represents the composition of data management services that, according to the legacy service policy, will produce results and an evaluation of their quality at the same time. To do that, the orchestrator begins invoking a service of the data management layer, in this case the data provenance service that certifies the provider. The results can be used by the service caller to refine authentication data as well feed back the data provenance service. This result will improve the data quality evaluation in subsequent data source service invocations.
7. Use Cases
In order to prove the effectiveness of our approach, we tested our system with many different user profiles (such as users with reduced mobility, elderly people, blind users, and users with low vision). In this section, we present two scenarios illustrating urban accessibility issues involving a wheelchair user and an elderly user. More generally, different scenarios can be pictured, involving all the different aspects of the smart mobility context. For instance, an interesting use case can be envisioned by considering a bicycle-sharing system together with subway/bus stops: real time subway/bus information are automatically provided by the transportation provider company, while data related to the bicycle-sharing stations with available bikes or open docks are crowdsourced by users and/or derived by crowdsensed data obtained in the activity of bike block/unblock, exploiting, for example, RFID/NFC technologies and GPS position. In this way, the SMAll system can compute personalized paths by taking into account the actual time of the interested subway or bus and the effective availability of bikes or of open docks suggesting the best bicycle-sharing station to reach, according to the defined destination of the route.
Another interesting use case that we are currently developing involves particular rural areas, whose main features are a low population density and a difficult road conditions due to rugged environmental conditions.
For these particular areas, in general, many public transport services such as buses and trains are not economically justified by the current demand. Conversely, however, more accessible urban public transport services become essential to reach other important social services such as healthcare which are often far apart.
SMAll provides the following solution. The public transport network is acting as a targeted service on request for each applicant. A network of taxis satisfies every single request. The SMAll task is to coordinate the various taxi operators who have the assigned races, from call handling to profit redistribution. SMAll would deal to merge close calls in an efficient way (e.g., Uber Pool).
The advantage is twofold, the administration spends less to provide a service and the quality of the service for citizen is improved. Moreover, this can be considered an example of fostering and supporting community awareness in rural area [55].
In the two user cases here detailed, the users request personalized paths, by using their own smartphones. In particular, let us consider a male user equipped with a manual wheelchair (first scenario) and an elderly woman (second scenario); both of them ask for a specific path (including bus routes) in the city of Bologna (Italy), with the same starting point A and the same destination B (shown in Figures 7 and 8). The path usually proposed by the most commonly used geospatial mapping platforms (e.g., Google Maps, Bing Maps) takes 17 minutes as a whole and is structured in three parts:(i)A pedestrian part to reach the bus stop: this part is supposed to take 8 minutes to the user.(ii)A part of a bus route (from the blue bus stop to the green bus stop): this part is supposed to take 8 minutes (with four in-between stops).(iii)Another pedestrian part from the arrival bus stop to the final destination: this part is supposed to take 1 minute.
This path presents some issues our users have to face:(1)There is a stair in the first pedestrian part of the path and there is no information about its presence; this means that our wheelchair user cannot afford the suggested pathway, but he has to find another alternative and accessible route.(2)There is no information about accessibility of the public mean of transport and of the bus stops; in particular, not all the vehicles are provided with facilities to support our specific user, such as ramps, kneeler features, and lifts.(3)Estimated time to reach the departure bus stop from the starting point (8 minutes, for 600 meters) is computed taking into account abilities and speed of an average user, instead of considering the actual abilities average speed of our specific users.(4)Information about bus arrival time is derived from a time table, instead of referring to the real bus position and availability.
The following subsections detail the scenarios about the sensing and the data consuming activities of two different users with different needs and preferences about the urban environment. The design of the interface is under investigation and some preliminary results can be found in [56].
7.1. First Scenario
As a first scenario, let us consider a wheelchair user who asks for an accessible path starting from A to the destination B. He has set up his UAProfile declaring that he stated as LIKE ramps and curb cuts (as gap facilities), parking slots reserved to people with disabilities (as parking facility), sidewalks with an adequate width (in the pathway category), and zebra crossing and traffic lights (as crossing facilities). He initialized uneven road surface and tactile paving (in the surface category) as DISLIKE and Gap category aPOIs and obstructions barriers as AVOID. Handrails and audible traffic lights are NEUTRAL for him, as well as street lighting. Algorithm 1 shows a fragment of his profile in JSON format.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When this user asks for a path from the starting point A to the destination B, then our system computes a personalized route taking into account the users profile (i.e., avoiding such barriers which affect him and including as much as possible the LIKEd facilities).
Our system computes a personalized path, by taking into account real data about bus availability and the users profile, in terms of barriers to avoid, LIKEd facilities to include as much as possible, and users personal average speed (set up as 0.98 m/s, according to [57]). This path is structured in three parts (shown in Figure 7), where only the first part is different from the path previously described. In particular,(1)our path suggests a different first pedestrian part of the path, taking into account the presence of that stair, and finds an alternative accessible path, including a ramp (highlighted in Figure 7 with a green icon);(2)information about the accessibility of the public means of transport is provided; in particular, the path is computed taking into account a bus equipped with a kneeler and wheelchair anchorage features;(3)estimated time to reach the departure bus stop from the starting point is computed taking into account our specific users abilities and average speed, as declared in his profile (16 minutes, for 900 meters);(4)information about bus arrival time is provided taking into account open data about the real bus position and eventual delays, provided by the local public means of transport operator.
The time to complete the path is estimated to be 30 minutes and it is computed according to the users average speed and real bus availability (by considering real time data about eventual delays, traffic, and so on, coming from open data made available by the public transportation provider), as follows: 16 minutes for the first part, 12 minutes for the second part, and 2 minutes for the last one. Meanwhile, crowdsensing and crowdsourcing services are exploited on the user’s mobile device, with the aim of collecting data and reports about urban barriers and facilities.
7.2. Second Scenario
As a second scenario, let us consider an elderly woman who asks for a path from A to B, tailored according to her preferences. She has set up her UAProfile declaring that she stated as LIKE streets lighting, crossing facilities, sidewalks, ramps, curb cuts, and handrails. She also stated as LIKE stairs, because her doctor suggested her to do some exercise, climbing stairs. She stated as DISLIKE garbage bins, while steps, gaps, uneven road surface, and tactile paving are NEUTRAL. Algorithm 2 shows a fragment of her profile in JSON format.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Once such a user asks for a pedestrian path, our system computes a personalized route from the starting point (A) to the destination point (B) taking into account her profile (i.e., stairs) and real data about bus availability. Also in this case the personalized path is structured in three parts and it is similar to the one previously described, including the stairs in its first part. Since this user is equipped with a smart phone, she would actively provide data coming from her mobile device accelerometer, so as to enrich the available information that are exploited by SMAll, with the aim of equipping citizens with smart mobility applications and data.
8. Conclusion
Smart mobility is a key point in supporting citizens in their daily activities and in offering them a feasible smart city. Information about urban transportation (including taxis, buses, trains, and car-sharing), urban barriers and facilities, and pedestrian and multimodal paths would be of great benefit in this context, as well as all the information about the whole experience of traveling and wandering the city, including travel planning and payments. Crowdsensing and Mobility as a Service can play a key role in this background. As discussed in Sections 3–6, in providing a complete and smart urban mobility service, different requirements need to be considered and orchestrated. In particular, an efficient service-oriented approach for smart mobility needs (i) real time data about public means of transport; (ii) updated urban data collected via crowdsensing and crowdsourcing; (iii) a model able to calculate the trustworthiness of collected data; (iv) a definition of a precise profile according to user’s preferences and needs. Keeping into account these design issues, we designed and prototyped an infrastructure as a marketplace for mobility services, called Smart Mobility for All (SMAll). A prototype of such infrastructure has been developed and its architecture has been described in the paper, as well as some of the provided services. In particular, two use cases have been presented, focusing on a wheelchair user and an elderly person. We are now doing further studies with the aim of profiling users by tracking their daily journeys, by exploiting machine learning techniques, integrating them in crowdsensing activities. Adaptation mechanisms will be applied to the profile, so as to dynamically and automatically modify it according to users actual abilities and habits. The adopted SOA approach will make all future additions easy to integrate, since each new algorithm or service will be developed as an independent microservice and plugged into the orchestration logic as needed.
As future work, we are planning to conduct the evaluation of the system in terms of (i) efficiency, scalability, and robustness and (ii) effectiveness, user experience, and usability.
Competing Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.