Architectural Vision

travellers, floating cars, the road network or public transport officials.

 Real-time:

Data and events have to be processed in real-time. E.g., this is an important system property for the navigation and routing applications. Another example is the traffic operator who needs to be immediately informed about critical traffic situations to undertake concrete compensation actions. In this context, the term “real-time” means that the usefulness of a result degrades after a deadline is missed. This is also referred to as “soft real-time” in the area of real-time computing.

 Distributed:

Not only processing nodes of the system are distributed over the network to create a robust and scalable system. In addition, the data producers (like road side units, floating cars) and the potential service consumers (like travellers) are distributed over the network as well. In this context, a number of different nomadic devices like in-vehicle systems or mobile phones are part of the system as well. They might act as both data producers and consumers. Thus, the Instant Mobility system can be considered as a “heavily” distributed mobile system.

The provided functionalities of the different scenarios focus on metropolitan areas. This also needs to be reflected by the system architecture to be able to meet the real-time constraints. Particularly, this is required to achieve the geographically scalability of the system. The basic idea is to deploy a metropolitan-specific set of Instant Mobility services on a “metropolitan-near” located cloud infrastructure. Thus, it is ensured that data is efficiently processed next to its production.

Figure 46 summaries the basic assumptions and shows a high-level view of a metropolitan-specific Instant Mobility instance.

Figure 46: High-Level View on the Instant Mobility System

Basically, the functionalities of the Instant Mobility ecosystem are offered by a RESTful (Representational State Transfer) Web Service interface layer. These services form the basis to build the scenario-specific applications of the different scenarios (e.g., Web portals, mobile applications, etc.). For efficient distribution of data between data producers and data processing components, an efficient real-time enabled data distribution middleware is required. However, these systems introduce a relative tight coupling between components with regard to the exchanged data. E.g., a major change of the data model could force a re-deployment of all involved components. Thus, a complementary communication middleware system is required as well which supports flexible, context-based publication of and subscription to data events. The major use case is to provide context-aware information to external systems. This approach results in a great flexibility when adaptions of the interaction patterns or the system architecture are required. Finally, to achieve an elastic scalability of the overall system, the components run on a cloud infrastructure.

Figure 47 sketches the idea of an Instant Mobility federated system.

Figure 47: Instant Mobility Federation

The basic idea is to deploy the required Instant Mobility components on a cloud infrastructure which is located next to a metropolitan area. In particular, the different Instant Mobility clouds have to be able to communicate, for instance, to transparently hand-over a traveller`s itinerary in case of an inter-metropolitan journey. Another use case might be the quick dissemination of traffic events which have the potential to sustainably influence the traffic situation in another metropolitan area.

6.2.2.2 Conceptual Architecture

Figure 48 shows the foreseen conceptual architecture of the Instant Mobility system. The following sub-sections describe the specific layers of the multi-tiered architecture in more detail.

Figure 48: High-level conceptual architecture

6.2.2.2.1 Application Layer

The application layer contains the different end user applications and administrative user interfaces which are developed in context of the specific scenarios. The basic idea is that the end user applications are built on top of the API which is provided by the underlying service layer. For instance, the traveller companion application calls the RESTful Web Service for planning a future journey which is provided by the Multi-Modal Mobility sub-system.

The target platforms vary from scenario to scenario. Basically, the different scenarios require the development of Web-based applications or applications which run on mobile devices or even on in-vehicle devices.

6.2.2.2.2 Service Layer

The service layer exports the functionalities of service components in a standardized manner using RESTful Web Services. Thus, it functions as the dedicated facade to the Instant Mobility ecosystem. Primary, this layer provides the functionality which is used to implement the various end user and management applications. In addition, it serves as an open, standardized integration layer and entry point for third-parties like data providers. Additionally, the service layer allows the re-use of the Instant Mobility functionality.

By applying the REST principles to the service layer, the service API is provided as a scalable facade which is able to guarantee the same level of Quality of Service even with a largely increasing number of client requests. In addition, REST provides the foundation to ensure interoperability with a heterogeneous client environment and to safely evolve the service API.

6.2.2.2.3 Service Component Layer

This layer contains the server-side components, which implement the business logic of the Instant Mobility ecosystem. Every component exposes its public API through RESTful Web Services.

Thus, the APIs of all components effectively build the service layer. Figure 48 shows the high-level components of the different scenarios and example interactions.

Additionally, Figure 49 and

Table 1 provide a summary of the different subsystems and their dependencies.

Figure 49: High-Level overview of the Instant Mobility Subsystems

Table 1: Summary of identified subsystems

Subsystem Description

Multi-Modal Mobility

- Provides the core real-time navigation and routing functionality - Covers aspects like multi-modal journey planning, itinerary

monitoring, and notification of travellers

Payment

- Provides services to include pricing offerings of different transport providers

- Handles seamlessly all payment issues of the traveller by means of virtual tickets

o Provides location-aware and situation-aware information to the traveller advertise their transport offerings and to operate and optimise their offerings in accordance to the demand

Traffic Manager

- Enables a complete supervision of an area on the basis of collected traffic information

- Implementation of “virtual” road side units

- Provides front-ends to different stakeholders for optimised presentation of traffic information

Goods Transport - Supports sharing and optimisation of transport resources

Manager - Supports dynamic drop point negotiation between consignee and storage or information retrieval) by dedicated abstract interfaces.

From an analysis of the foreseen scenario-specific components, the following backend interface types have been identified:

 Data Storage and Backup:

Reliable data persistence is relevant for every scenario. In this context, statistical or operational data has to be stored. However, there is also the need to process structured and semi-structured data across the scenarios.

 Real-time Traffic Data:

Traffic-related data is relevant for the scenarios “transport infrastructure as a service” and

“personal travel companion”. One shared requirement is that data events have to be distributed to data processors in real-time as soon as they occur. In this context, collection of location-based data and data originating from traffic infrastructure components is required.

 Traffic Control:

This interface enables a service component to interact and send commands to a traffic infrastructure component like a road side unit or a traffic sign. Thus, it requires interaction on a thing level. This interface is particularly relevant for the “transport infrastructure as a service”.

6.2.2.2.5 Communication

Figure 50 sketches the foreseen communication architecture by showing the interactions between selected components. Components are assigned to a specific architectural layer. Additionally, communication flows, communication middleware components and provided interfaces are illustrated.

In the following we summarise the foreseen communication options:

 Point-to-point communication:

In this context, the involved components directly interact with each other in a synchronous request-response manner. For that purpose the corresponding service components expose

specific RESTful Web Services.

An example is a request of the Transport Exchange Portal to the Multi-Modal Mobility subsystem to provide alternative itineraries for transportation route optimisation. Another example is the request of the Personal Traveller Companion application to plan a journey.

 Context-based publish-subscribe communication:

This communication option supports flexible, context-based provision of data to the world of final consumers (e.g., other platforms, components, end user applications). I.e., data

consumers can take into account the situation in which a specific data element has been produced. This results in a great flexibility when adaptions of the interaction patterns are required. The required middleware should be provided by the Context Broker GE²³. The Context Broker GE exposes a RESTful Web Service interface which can be used for publication of context-aware data and to allow context-based subscription to data events.

An example is that the Personal Traveller Companion mobile application which only takes specific itinerary events into account (e.g., changed route notification) while ignoring other events (e.g., advertisement events).

 Real-time, data-centric publish-subscribe communication:

This communication option supports real-time data sharing between data producer and data consumer components. In this context, the data model should be quite mature (at best following established standards) because major changes might require a re-deployment of the involved components. In this context, the communicating components are required to implement IDL-based interfaces which fit to the published data format. The required middleware should be provided by the Advanced Middleware GE²⁴. This GE addresses a

maximum level of system performance and scalability.

Real-time data sharing is particularly required by the data collection and data processing components of the Multi-Modal Mobility and Traffic Manager subsystems. In this context, formats of exchanged data are often compliant to established standards. Thus, we do not expect major changes of resulting data models.

23.http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/

24.https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE

Figure 50: Communication Architecture

D31.1 -3.1 Platform state-of-the-art review

6.2.2.2.6 Security

Communication between components is basically performed on basis of RESTful Web Services which utilise the HTTP protocol. Securing HTTP communication is well investigated topic. Thus, basically we can rely on well-established authentication like TLS (Transport Layer Security). TLS is standardised by the IETF²⁵ and utilises different cryptography mechanisms in a flexible manner (e.g., asymmetric cryptography for key exchange, symmetric encryption to ensure privacy, message authentication codes to ensure message integrity). Thus, TLS provides secure point-to-point communication.

6.2.2.2.7 Federated Authentication

For authentication the use of federated authentication mechanisms rather than providing an own, dedicated system is valuable. The OpenID 2.0 standard has been considered in order to provide a federated authentication infrastructure and to enable single sign-on²⁶.

6.2.2.2.8 Delegated Authorisation

As Instant Mobility provides a RESTful Web Service API, there are also use cases in which point-to-point secured connection are not sufficient. Particularly, the user`s application might invoke a service which in-turn needs to make another service call on behalf of the user. Thus, a mechanism for authorisation delegation is required.

For RESTful APIs, OAuth 2.0 is the mean of choice and is already widely adopted. Instead of transferring user credentials from one communication endpoint to another, a security token of restricted lifetime is used to indicate that an application acts on behalf of the user.

OAuth introduces an authorisation server which is in charge of issuing security tokens and authenticating end users. The application request the security token from the authorisation server and sends the

authorisation code for that purpose. For further technical details, we refer to DraftOAuthV2²⁷ and OAuth2Introduction²⁸.

6.2.2.2.9 Privacy

The collection of location information, both real-time locations and permanent locations (e.g., home address), requires special considerations because:

 The disclosure of this information might cause consequences for privacy and physical safety of the user.

 The simple transmission of a location may allow near-perfect personal tracking.

 Location tracking can reveal a user`s home address and employer by looking for typical night and day-time locations, even without identifying information.

Figure 51 shows the identified security data flow. The basic idea is to make use of pseudonym certificates to establish the trust between the Instant Mobility services and the traveller. The pseudonym certificate holds some verified attributes which allow services to make certain assertions about the traveller but still hides his/her identity.

TRAVELLER

TravellePseudoCertificr or Divatenym er Secu

However, the “free” availability of fine-granular location information might still allow re-identification of anonymised users.

For that purpose Instant Mobility requested the extension of FI-WARE`s current privacy concept by a location monitoring component. This component should monitor the real-time location of anonymised users. Particularly, it is the only component which obtains this kind of information. The user might explicitly allow or disallow which events (e.g., planned itinerary delay, proximity alert) might be received by whom. Thus, only authorised parties can subscribe to this information and are notified.

The component might also publish anonymised information about traveller`s movements. However, to publish location data without compromising privacy, either a spatial-domain or a time-domain approach has to be used. I.e., the traces are either

 at coarse granularity levels so that the anonymity sets are large enough to preserve privacy (e.g., the location granularity is at city level or above) or

 too short to make it difficult/impossible to infer locations correctly.