H2020 – Contract

No 826385 – MaaSive

Enabling MaaS in the IP4 Ecosystem

D7.3 – TD4.5 CREL Implementation Report

Due date of deliverable: 31/12/2019

Actual submission date: 31/12/2019

Leader of this Deliverable: Diginext

Reviewed: Diginext

Document status Revision Date Description 00-00-01 13/12/2019 Initialization of the document 00-00-02 13/12/2019 First draft sent to the partners 00-00-03 19/12/2019 Contribution from partners 00-00-04 20/12/2019 Intermediary version 00-00-05 20/12/2019 Intermediary version 00-00-06 19/12/2019 Contribution from partners 00-00-07 19/12/2019 Contribution from partners 00-00-08 19/12/2019 Integrated version from partners contribution 00-00-09 20/12/2019 Final version 00-01-00 16/01/2020 Reworked version after review

MAAS-WP7-D7.3D4.5 Page 1 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Project funded from the European Union’s Horizon 2020 research and innovation programme Dissemination Level PU Public X CO Confidential, restricted under conditions set out in Model Grant Agreement CI Classified, information as referred to in Commission Decision 2001/844/EC

Start date of project: 01/11/2018 Duration: 31 months

MAAS-WP7-D7.3D4.5 Page 2 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

EXECUTIVE SUMMARY This document reports the implementation details of the development work carried out within the CREL version of the project MaaSive for the Travel Companion. This deliverable describes the implementation of the Core Release, which represents the whole work done for TD4.5 during this first period of the project.

Based on the CREL Specification and on the results of the ATTRACkTIVE’s project we integrated new concepts for the Travel Companion. More than ever designed around the user as the centre of the ecosystem, this new implementation includes new concepts to cover group traveling, Mobility as a Service, mixed reality experiences and a web front experience.

Within this CREL, the focus is to define and test the architecture of the Travel Companion with these new components. In addition, these first developments aim to provide new components and to connect all of them to the one already developed in ATTRACkTIVE’s final release.

MAAS-WP7-D7.3D4.5 Page 3 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

TABLE OF CONTENTS

Executive Summary ...... 3 List of Tables ...... 8 1. Introduction ...... 9 List of acronyms ...... 10 Referenced Documents ...... 13 2. Implemented Software Components ...... 14 Implemented architecture ...... 14 the framework ...... 14 Reference to API description ...... 15 Implementation choices ...... 15 Misalignments with specifications ...... 16 EMBODIMENT Management ...... 16 Reference to API description ...... 17 Implementation choices ...... 17 Misalignments with specifications ...... 17 Mobility packages management ...... 17 Reference to API description ...... 19 Implementation choices ...... 20 Misalignments with specifications ...... 20 LBE watcher ...... 20 Reference to API description ...... 20 Implementation choices (Technology, processes...) ...... 20 Misalignments with specifications ...... 22 LBE launcher module ...... 22 Reference to API description ...... 24 Implementation choices ...... 24 Misalignments with specifications ...... 24 Mixed Reality Engine...... 24 Reference to API description ...... 25 Implementation choices ...... 25 Misalignments with specifications ...... 26 Mixed Reality Composer ...... 26 Reference to API description ...... 26 Implementation choices...... 26

MAAS-WP7-D7.3D4.5 Page 4 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Misalignments with specifications ...... 28 Web Front End ...... 28 Description of the implementation ...... 29 Reference to API description ...... 38 Implementation choices ...... 38 Misalignments with specifications ...... 39 3. Testing at component level ...... 39 Use cases to be validated ...... 39 Dependencies ...... 40 Testing tools ...... 40 Testing procedure ...... 41 4. Test case descriptions ...... 42 Framework ...... 42 Test 1 ...... 42 Embodiment Management ...... 42 Test 1- display the valid token ...... 42 Mobility Packages Management ...... 43 Test 1- scanning physical travel cards ...... 43 Mixed Reality Engine...... 44 Test 1- MR experiences on the devices ...... 45 Test 2- Run the experiences on the devices ...... 45 Mixed Reality Composer ...... 46 Test 1- Automatic Testing of the MIXED REALITY COMPOSER: ...... 47 Test 2 - Manual Testing of the MR composer: ...... 49 LBE Launcher module ...... 49 Test 1-Launch Experiences: ...... 49 Test 2-Stop Experience: ...... 50 LBE Watcher module ...... 50 Test 1- Test the watcher module: ...... 50 Web Front End ...... 51 Test 1-Test user registration ...... 52 Test 2-Test user Login ...... 52 Test 3-Test Preferences screen ...... 54 5. Test reports ...... 55 6. Summary and recommendations for next steps ...... 56

MAAS-WP7-D7.3D4.5 Page 5 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

List of Figures

Figure 1: Framework Architecture ...... 15 Figure 2: Methods used ...... 17 Figure 3: Screenshots of the Tariffs screen for uploading and existing MP ...... 18 Figure 4: Screenshots of the module detecting a physical card: ...... 19 Figure 5: MR Device and mobile device local network ...... 21 Figure 6: ARP Cache table ...... 21 Figure 6: Communication between LBE Watcher and MR Device ...... 22 Figure 6: Mockup of the launcher experience ...... 23 Figure 9: MR Experience running screen ...... 23 Figure 7: Communication between LBE Launcher and MR Device ...... 24 Figure 10: Integration of ANGLE in the Mixed Reality Engine ...... 26 Figure 11: UX design for Home page of the TC Web ...... 30 Figure 12: UX design for user registration in the TC Web ...... 30 Figure 13: UX design to manage user profile and preferences in the TC Web ...... 31 Figure 14: UX design for trip searching in the TC Web...... 31 Figure 15: UX design to select ancillaries in the TC Web ...... 32 Figure 16: UX design to book a trip in the TC Web ...... 32 Figure 17: UX design for user payment in the TC Web ...... 33 Figure 18: UX design for cancellation in the TC Web ...... 33 Figure 19: Home page of the TC Web ...... 34 Figure 20: Registration screen in the TC Web ...... 35 Figure 21: Login screen in the TC Web ...... 36 Figure 22: Direct access buttons in the TC Web (top right) ...... 36 Figure 23: Screen to manage personal data in the TC Web ...... 37 Figure 24: Screen to manage preferences in the TC Web ...... 37 Figure 25: Schema of the Angular architecture proposed for the TC Web ...... 38 Figure 26: TC interaction with other TDS ...... 40 Figure 27: Token activated for use at “Next Access Gate” ...... 43 Figure 28: Result of scanning a card ...... 44 Figure 29: Process of how to start the experience on the Glasses ...... 45 Figure 30: A snapshot of a daily build report...... 47 Figure 31: A snapshot of the Mixed Reality Composer through the LBE editor daily test report .... 48 Figure 32: A snapshot of the MR composer within the LBE editor daily test result report...... 48 Figure 33: Screenshot of the experience’s list regarding the different devices (a): the glasses, (b): the phone ...... 51

MAAS-WP7-D7.3D4.5 Page 6 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 34: Introduction of user info for registration ...... 52 Figure 35: Success message ...... 52 Figure 36: Introduction of user info for login ...... 53 Figure 37: Success message ...... 54 Figure 35: User Photo/avatar, from which the preferences are accessed ...... 54 Figure 39: Change preferences ...... 54 Figure 40: Success message ...... 55

MAAS-WP7-D7.3D4.5 Page 7 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

LIST OF TABLES Table 1: Referenced documents ...... 13

MAAS-WP7-D7.3D4.5 Page 8 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

1. INTRODUCTION To find one single application that can help you during your travels by providing all kind of information and notifications regarding your tickets and trips, etc. for your Pan European travel is not easy.

In this way, the IP4 TD4.5 initiative aims to handle sophisticated door-to-door travels through a Travel Companion supporting different transportation modes, from private bikes to all kinds of public transport and air.

This Travel Companion for MaaSive’s project will provide more and more services to users allowing them to travel in groups, experimenting new concepts to entertain them through mixed reality and all of this with MaaS services.

This document summarizes the implementation of the different functionalities identified for the CREL version for the Travel Companion.

The first section deals with the description of the different components that have been implemented for this CREL. We then present the tests carried out for each of these components.

The last two sections describe the integration and tests report carried out for the CREL at component level. The document finishes with a conclusion and description of the next steps.

MAAS-WP7-D7.3D4.5 Page 9 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

LIST OF ACRONYMS Acronyms Meaning

AR Alternative RouteRoute

AMA AMADEUS IT Group SASA

AWP Annual Work PlanPlan

CEP Complex Event ProcessingProcessing

CMMP Contractual Management Market PlacePlace

CREL Core ReleaseRelease

CW Cloud WalletWallet

DMP Data Management PlanPlan

dpTT disruption partial Trip TackerTacker

DXT DIGINEXT SARLSARL

EC European CommissionCommission

EE Experience EngineEngine

EMV EuroCard, MasterCard and VisaVisa

ES Event Sources

ETA Expected Time of Arrival

EV Event

FREL Final Release

GA Grant Agreement

GTFS General Transit Feed Specification

GUI Graphical User Interface

HAC HaCon Ingenieurgesellschaft mbH

HIT Hitachi Rail STS SPA

ID Identification

IDB Interface Diagram Blank

MAAS-WP7-D7.3D4.5 Page 10 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

IF Interoperability Framework

IND INDRA Sistemas S.A.

IP4 Innovation Programme 4

ITD Integrated Technology Demonstrator

LBE Location Based Experience

LH LightHouse

MaaS Mobility as a Service

MP Mobility Package

MUC Multy User Capability

NA Not Applicable

NFC Near Field Communication

NR NETWORK RAIL Infrastructure Limited

OCR Optical Character Recognition

PA Personal Assistant; Personal Application

POI Point of Interest

PRM Person with Reduced Mobility

PSC Project Steering Committee

pTT Partial Trip Tracker

R&I Research and Innovation

RFID Radio-Frequency Identification

RT Real Time

S2R Shift2Rail

SBP Software Best Practices

SC Steering Committee

SIRI Service Interface for Real Time Information

SPD System Platform Demonstrator

TC Travel Companion

MAAS-WP7-D7.3D4.5 Page 11 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

TC – PA Travel Companion Personal Application

TC – CW Travel Companion Cloud Wallet

TD Technology Demonstrator

THP Thales Portugal S.A.

TO Tracking Orchestrator

TRIAS Traveller Real Time Information and Advisory Standard

TT Trip Tracking

UI User Interface

VDV Verband Deutscher Verkehrsunternehmen (Association of German Public Transport )

WP Work Package

WS Web Service

MAAS-WP7-D7.3D4.5 Page 12 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

REFERENCED DOCUMENTS

Reference Title Revision Date Number 1 MAS - D7.1 – TD4.5 CREL Specifications Final 2 MAS - D7.2 Mixed Reality Device Evaluation Report Final 3 ATT - D2.5-FREL Implementation Report Final 4 Navigator-Library-Interface-Definition-Android-v4.110 Final

Table 1: Referenced documents

MAAS-WP7-D7.3D4.5 Page 13 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

2. IMPLEMENTED SOFTWARE COMPONENTS This section describes the different components that have been implemented during this first release. Based on MaaS, the Travel Companion provides new concepts to be integrated. Before implemented, these components have been specified; for more detail refer to D7.1 – TD4.5 CREL Specification

.

These new components aim to provide the necessary functions to the Travel Companion Personal Application, but that is not their only aim.

For this reason, the framework will further extend the approach to support the novel Mobility as a Service features such as multi-modal entitlement management, the trip informer system as well as the mixed reality engine, as well as to support the novel devices. Correspondingly, this release will design and implement the entitlement management module that provides the tokens on the Travel Companion, which enables a traveller to easily validate his ticket easily.

Furthermore, mixed reality experiences will be proposed to the travellers for the FREL to entertain them during their trip. Modules to allow this are specified and implemented.

IMPLEMENTED ARCHITECTURE The Travel Companion PA architecture is based on the one defined and implemented in the ATTRACkTIVE project. This architecture is such flexible that additional libraries can easily be integrated. The CREL Implementation shows no difference from the foreseen architecture in the specification. The description how modules have to be designed is part of the document “Navigator- Library-Interface-Definition-Android-v4.110”1.

THE FRAMEWORK The figure 1 shows the architecture of the Travel Companion. It consists of the Event Bus, which acts as the central communication link. Following modules are linked to this bus:

 Traveller Feedback  Sensor Data Module  Notifications Display  Identity Manager  Embodiment Manager  Data Persistence Module  Payment Manager  Local Positioning Provider  Group Manager  Tariff Module  Experience Engine

1 Navigator-Library-Interface-Definition-Android-v4.110

MAAS-WP7-D7.3D4.5 Page 14 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

 Personal Shopper  Personal Booker  Personal Issuer  Travel Arranger Module  Token Activator  Alarm Manager

The Side-Drawer component is an integral part of the Framework. It defines which side draw entries are shown according to the current status of the system.

Figure 1: Framework Architecture

Reference to API description Not applicable for the Framework

Implementation choices The Travel Companion PA is developed as an Android Application. All regulation related to the application definitions are taken into account. Within the ATTRACkTIVE Project, the system is based on the Android Library with 32 Bit. In MaaSive the system is switched to Android X as next generation which is based on 64 Bit.

MAAS-WP7-D7.3D4.5 Page 15 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Misalignments with specifications Not applicable

EMBODIMENT MANAGEMENT This is not a new module, but an evolution of the existing library deployed in ATTRACkTIVE (EmbodimentManager.sdk). The evolution enables the TC to select which token should be used at each moment. This would be especially important in the situation where all tokens for the same trips are “wrapped” in a unique token (planned in WP3 and WP4). Three possibilities have been identified to provide this functionality:

 Manual trigger: Once in the station, the user selects the leg of the trip from the MyTrips screen  Logical position trigger: The systems shows the next leg in the trip, based on logical position  Infrastructure trigger: Based on GPS position, beacons or QR codes installed in the infrastructure, that indicates the station/TSP

They rely on a new component deployed called “Token Activator”. For the CREL, only the second option has been specified and implemented.

For this second option, the token library makes use of the LogicalPositionProvider.sdk developed in ATTRACkTIVE. With this module, the Embodiment Manager is able to detect the current position and the “next access gate” (based on the timings of the planned trip), defined as the next travel episode in which the token will be needed for validation at the entrance gate. Figure 2 shows screenshots of the code that calls the Activator module and the methods of the Logical Position Provider module.

LogicalPositionProvider logProv=new LogicalPositionProvider(); StringBuilder travel_destination_name = new StringBuilder(); travel_destination_name.append("Next access gate: "); travel_destination_name.append(logProv.getCurrentTravelEpisode().getEndLocation(

MAAS-WP7-D7.3D4.5 Page 16 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

).getName()); payloadStructure.put(travel_destination_name.toString(), "DATA_INFO_COMPANY"); createQR(payloadStructure);

Figure 2: Methods used

Reference to API description A specific API is not necessary because it calls the CW (Offers Manager API, deployed in ATTRACkTIVE) to get the offer. The complete documentation of this CW service is accessible in: http://test.indra.shift2railcloud.com:8080/offersmanager-1.0.1/swagger-ui.html

Implementation choices This library of the application is provided as an apk. This apk is an executable file on the Android platform. For MaaSive, the new version of Android is used (Android X), being more powerful than the previous version used in ATTRACkTIVE.

Misalignments with specifications Not applicable for this component

MOBILITY PACKAGES MANAGEMENT This section explains the deployments done to allow a user to select a Mobility Package (MP) among a list of existing ones. The specifications contemplate two options: one is that the user selects the MP and then purchases it, and the other one is that the user already has a “physical card” (such as a monthly pass) and wants to register the card reference linked to its S2R user account.

For the CREL, only the second option has been deployed at TC level.

This functionality enables the user to select a MP (including cards and passes) and upload the card information automatically. The users need to go into the “Tariffs” screen, and they will see a list of available MP (Figure 3- left). These are uploaded in the ecosystem through the CMMP, therefore this process will not be explained in this document. The users can select among them the one they already have purchased and from which they have a physical card, and press “upload” (Figure 3 - right). Ideally, in the future, everything could be digitalized, but now the reality is that these physical cards are widely spread and they will not disappear overnight. Therefore, IP4 ecosystem should find a way to consider them in the calculation of offers.

MAAS-WP7-D7.3D4.5 Page 17 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 3: Screenshots of the Tariffs screen for uploading and existing MP

This TC module implements an automatic process to ease the registration of the card reference. This is based on Optical Character Recognition (OCR). For the registered cards, the OCR engine knows where the ID of the card is located, and the users only need to scan the card with the application. The application will automatically see the relevant information and will store it in the CW together with the user information (Figure 4).

MAAS-WP7-D7.3D4.5 Page 18 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 4: Screenshots of the module detecting a physical card:

Reference to API description The API for the Tariffs module follows the following structure:

[{

"id":"string",

"name":"string",

"description":"string",

"image":"integer",

"price":"float",

"operator"string"

}]

MAAS-WP7-D7.3D4.5 Page 19 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Implementation choices A similar approach could be followed using NFC (reading NFC information instead of using optical recognition of characters). The optical based has been selected to demonstrate the approach for the CREL, but the approach based in NFC could be also valid and may be implemented in the future.

Misalignments with specifications Not applicable for this component

LBE WATCHER

As designed in the ATTRACkTIVE project, the LBE watcher enables the launcher to display the available experiences when appropriate, according to the traveller’s preference and current location. This Watcher was enhanced on the MaaSive version in order to support new mixed reality devices.

The watcher is now able to distinguish the experiences according to the location and preferences but also according to the available devices.

When published, the experiences contain a manifest file describing the needed conditions to propose the experience and the devices on which theses ones will run.

The Watcher parses all the experiences, read their manifest and then executes a filtering algorithm. As output, this new version of the Watcher module gives a filtered list of experiences usable by the Launcher. The user interface responsible of displaying the experiences can display separately the ones available on the mobile device to the ones available on the connected mixed reality devices, such as glasses or watches.

Reference to API description Not applicable

Implementation choices (Technology, processes...)

2.5.2.1 Connection to the Mixed Reality device The mixed reality device acts as an extension of the PA executed on the mobile device. To do so, we need to establish a connection between both devices. The classic techniques for wireless pairing between two devices are bluetooth and wifi. In our case, we use a Microsoft Hololens 1 headset to test the use of mixed reality in a travel context. This headset does not allow to pair in bluetooth any other device than keyboard or mouse. Then we had to use a Wifi connection. The easiest way to do so, to not be dependant of an external infrastructure is to create a local network where both devices are connected. The mobile is configured as a hotspot wifi, on which the mixed reality headset connects. The two devices are thus accessible to each other since they are on the same local network (Figure 5).

MAAS-WP7-D7.3D4.5 Page 20 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 5: MR Device and mobile device local network In order to avoid the user to enter an ip address, we have implemented a function that allows discovering the headsets present on the network. The first implementation used a scan ip command, unfortunately the hololens helmets do not respond to this command. Therefore, we use the ARP cache to know all the devices connected to the local network (Figure 6). We then filter this list thanks to the MAC address in order to detect only the Hololens helmets. Finally, we connect to the first helmet found and accessible.

Figure 6: ARP Cache table

2.5.2.2 Getting available experiences Once the connection is established between the mobile device and the MR Device, the LBE Watcher access to the MR Device in order to get the available experiences on the device and the associated

MAAS-WP7-D7.3D4.5 Page 21 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

information needed such as Icon, Description, Parameters contained in the Manifest file. This is done by a succession of REST request sent by the LBE Watcher to the MR device represented in the Figure 7.

Figure 7: Communication between LBE Watcher and MR Device Once the LBE Watcher has got all available experience from the MR device, it get the all the experience available for the mobile device and combine both list to provide a complete list of all available experiences to the LBE Launcher Module.

Misalignments with specifications Not applicable

LBE LAUNCHER MODULE As well as the watcher, the LBE Launcher module was also improved to support the new mixed reality devices studied and tested during this release.

As defined in ATTRACkTIVE, this module aims to display the list of filtered experiences to the traveller. This functionality is achieved thanks to the filtered list of experience given by Watcher.

The Erreur ! Source du renvoi introuvable. shows the preview of the new launcher integrated in the PA. The user interface developed allow the user to display only phone compatible experiences, only MR device compatible experiences or both of them at the same time. Another functionality added to handle experience running on MR Device; it is the possibility to stop the experience from the same screen of the TC-PA.

MAAS-WP7-D7.3D4.5 Page 22 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 8: Mockup of the launcher experience Once the traveller has selected an experience into the list from the phone or the mixed reality devices, the Launcher will start the experience. From the parameters of the experience contained on the experience package, it launches the experience on the specific device and calls the Mixed Reality engine to correctly run the experience.

When the experience is started on the MR Device, a screen is displayed to the traveller. From this screen he can stop the experience.

Figure 9: MR Experience running screen

MAAS-WP7-D7.3D4.5 Page 23 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Reference to API description Not applicable

Implementation choices Contrary to the ATTRACkTIVE implementation, experiences can now be launched on a connected device and not only on the traveller mobile device. Unfortunately, the REST request mechanism implemented in the LBE Watcher cannot be used to start and stop a specific experience on the connected device from the PA. This is due to some access restrictions. Then starting the experiences and checking running experiences are done thanks to a TCP call to a service running on the MR Device. The Figure 10 below represents this communication between the MR Device and the Mobile device.

Figure 10: Communication between LBE Launcher and MR Device

Misalignments with specifications Not applicable

MIXED REALITY ENGINE The mixed reality engine component aims to provide the necessary function to support mixed reality devices. This component enables a traveller to experience a door-to-door journey using mixed reality concepts and devices, thus radically enhancing both the user-friendliness and attractiveness of multi- modal transport by turning travel into an engaging activity.

Moreover, as this component is deeply dependent on the devices that are novel and rapidly evolving, this component is based on a device-agnostic engine to support many Mixed Reality devices to foster the adoption of the S2R Travel Companion.

This engine

MAAS-WP7-D7.3D4.5 Page 24 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

 aims to orchestrate and manage the user’s experience on the selected devices. That means enhance the Experience Engine developed within ATTRACkTIVE to support a large wide of devices  expands the interactive experiences by integrating all computing capacities of theses Mixed Reality devices, including voice and hands interactions  interprets the traveller’s requirements and interactions and decides the next task sequence, based on the current user’s profile.

Within the framework of the CREL, work has been done in order to put in place an agnostic engine. This work remains quite conceiving because the ideal goal for it is to be able to be functional on a wide range of devices.

The engine is initially defined to support multiple devices, which does not allow us to leverage everyone's advantages.

Following our study on the devices (2), the most promising solution remains the Hololens that, which will be used for the FREL specification and implementation.

Therefore, a first implementation was carried out on this device while keeping the agnostic aspect. An additional work will be done during the FREL to adapt to this device as well suitable as possible.

Reference to API description Not applicable for this component

Implementation choices The first work has been done on Microsoft Hololens MR Glasses. The Mixed Reality features, such as localization, hands interaction and anchor storage are realized by using the classical windows API. Therefore, the mixed reality engine is now multiplatform compatible (Android and Windows UWP).

The 3D rendering on Hololens needs to be done thanks to DirectX API. The 3D rendering engine used in the original Experience engine was based on the OpenGL API. The work to modify the 3D engine to make it compatible with the DirectX API would require a lot of substantial work, which is not necessarily useful. In order to optimize the work and to avoid unnecessary efforts we decided to use a wrapper called Angle.

ANGLE (Almost Native Graphics Layer Engine) is an open source, BSD-licensed, graphics engine abstraction layer, developed by Google. The API is mainly designed to bring OpenGL compatibility to Windows computers by translating OpenGL calls to DirectX. The Figure 11 shows the improvement of the stack implemented within ATTracKtive project to insert the ANGLE Layer between our 3D Rendering engine and the graphical card available on MR Device.

2 MAS - D7.2 Mixed Reality Device Evaluation Report

MAAS-WP7-D7.3D4.5 Page 25 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 11: Integration of ANGLE in the Mixed Reality Engine

Misalignments with specifications Not applicable for this component

MIXED REALITY COMPOSER This Component provides a set of high-level blocks enabling Travel Experts to create easily Mixed Reality experiences for travel purposes.

This component will enhance the ATTRACkTIVE Location Based Experience Editor by adding novel Mixed Reality blocks that are easily customizable and publishable on devices such as smart glasses and headsets.

Based on blocs programming of the Location Based Editor, the mixed reality composer aims to provide the necessary elements to fully integrate the mixed reality concept.

Reference to API description Not applicable

Implementation choices... Adding MR capabilities to the ATTRACkTIVE Experience Editor is done thanks to the plugin modularity of the architecture. A new MR Plugin has been created. When the user creates a MR

MAAS-WP7-D7.3D4.5 Page 26 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Experience the corresponding plugin is loaded and enriches the editor libraries with specific assets (Block, Entities and Module)), and creates the needed graphical user interfaces.

For the CREL a minimal set of assets have been created:

 MR Device Cursor entity  MR Device entity  Spatial Anchor entity  MR Device Plug And Play

The three first ones are the basic elements to create a MR Experience.

The MR Device Cursor entity is aimed at visualise the target of the user’s gaze, which can be compared to a mouse cursor. It is a customized image entity, which automatically displays a cursor wherever the user is looking at. This entity is composed of the following attribute accessible from different panel:

 General panel: o Displayed: Boolean [Displayed], the visibility state of the entity during Experiencing. o MR Device Entity: Entity [MRDeviceEntity], the related MRMR Device entity. o Far : Real [Far], the default distance between the user and the cursor. o Near : Real [Near ] The minimum distance between the user and the cursor.  Appearance panel: o Scale : Vec3 [Scale], the 3D entity scale. o Opacity : Real [Opacity], the opacity of the cursor image.

Among appearance panel, there is the Cursor Image Files category used to custom the cursor image depending on the situation (default or by a hologram manipulation):

o Basic : URL [BasicCursorImage], the file that defines the default cursor image. o One Hand Manipulation : URL [OneHandManipImage], the file that defines the displayed image while user is doing a Move Gesture with one hand. o Two Hands Manipulation : URL [TwoHandsManipImage], the file that defines the displayed image while the user is doing a Rotation Gesture with two hands.

The MR Device entity represents a user wearing a Microsoft HoloLens headset. An Inscape project, which targets MR Device, must contain one, and only one. It is important to define its Camera attribute, since otherwise nothing is rendered on the head-mounted device. This entity is composed of the following attribute:

 Camera : Entity [Camera], the camera to be controlled by the headset device.  Position : Vec3 [Position] [RO], the head position tracked by the headset device.  Orientation : Quat [Orientation] [RO], the head orientation tracked by the headset device.

In order to interact with the user’s environment, it is possible to know the entity the user is looking at:

 Enable Targeting : Boolean [EnableTargetingEntity], enable or disable the search of the entity that is targeted by the user's gaze.

MAAS-WP7-D7.3D4.5 Page 27 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

 Targeted Entity : Entity [TargetedEntity] [RO], the entity that is targeted by the user’s gaze.  Targeted Position : Vec3 [TargetedPosition] [RO], the position that is targeted by the user’s gaze.  Manipulable Entities : Container of Entity [ManipulableEntities], the Entities in this list can be manipulated with gestures.

The Spatial Anchor entity represents an important point in the user’s environment. Some MR Headsets keeps tracking the user’s environment over time. As such, if any virtual object is placed in the environment, it remains nearly stable. To increase its stability, it must be GeomParented to a Spatial Anchor entity. However, the use of spatial anchors is mandatory to save an object position in the case the application is closed and then re-opened. Otherwise, the position is lost and the object must be re-positioned by the user. The spatial anchor entity is composed of the following attributes:

 Position: Vec3, the 3D entity position in its GeomParent frame. It can be directly modified using the Gizmothe Gizmo.  Orientation: Quat, the 3D entity orientation in its GeomParent frame. It can be modified directly by using the 3D Manipulator tool.  Scale: Vec3, the 3D entity scale. It can be modified directly modified using the the 3D Manipulator tool .  StagePosition: Vec3, the 3D entity position in the stage.  StageOrientation: Quat, the 3D entity orientation in the stage.  Displayed: boolean, the visibility state of the entity during Experiencing.  GeomParent: 3D Entity, the parent 3d entity to which the 3D entity is geometrically constrained. When a GeomParent is set (resp. not set), the position and orientation of the 3D entity depend on the GeomParent entity frame (resp. world frame)  Enabled: bool, enable or disable the entity's behaviour. When an entity is disabled, none of its graphs are started when the simulation starts. If an entity is disabled during the experiencing, the graphs are paused until the entity is enabled again.  Loading State : Integer [LoadingState], whether the anchor has been found and properly loaded (0 or Loaded means everything went well, 1 or LoadingFailed means the anchor failed to load, 2 or NotStored means this anchor has never been stored before)

The last entity MR Device Plug and Play is a specific entity composed of the three first in order to facilitate the MR Experience creation process.

Misalignments with specifications Not applicable

WEB FRONT END

A new feature of the MaaSive project is the development of the Travel Companion Web Front End (Web TC). Through it, the user can have access to many of the IP4 user functionalities from his computer (web browser) instead of the TC app. The TC app can be used afterwards during the trip to access to the information.

MAAS-WP7-D7.3D4.5 Page 28 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

New front-end components will be created for all functionalities, which at backend level will communicate with existing IP4 components that are also called from the app modules (for example the CW). The exchanges between the user and the S2R ecosystem through the TC Web are expected to be the same has from the TC app towards S2R.

According to the DoW, the CREL implementations have been focused on providing the following functionalities: registration, login and preference management.

After the specifications and design included in D7.1, the process for implementing the Web Portal has followed the next steps, which are the common steps in web programming:

 User Experience (UX): a team of experts has worked on the UX aspects, and has made an initial proposal for each screen (e.g. including buttons size and distribution on the screen) and then follows that guide of the interactions of the users. The team based the proposal on its previous experience in the domain, on the analysis of existing web pages related to travels, and, of course, in the current TC app design. They have also been supported by control groups inside the company, which were asked to give feedback on their experience. Sketch is the tool used for this Sketch.

Web Layout: during this process, the html to be deployed in the server is built. This is mainly the visual skeleton of the web page, without functionalities or communications among the screens or with the backend. It has been used for this stage.

 Implementation: after the previous steps, the development team has carried out the deployment of the functionalities covered in this release, using the Angular framework. The implementation covered the connection of the Web Layout with the existing backend, which for the functionalities covered in this phase (registration, login, and preferences) are mainly Cloud Wallet interfaces. This way, a user that is already registered through the TC app, can log in also in the TC Web with the same credentials.

Description of the implementation In this section several screenshots of the UX screens and from the implementation are included. The UX are considered as an ideal reference, followed as far as possible in the implementation, although at development time some decisions are taken that are more convenient or match better the implementation requirements.

2.9.1.1 UX screens UX analysis has been performed for the multiple services that will be offered by the TC Web, not only for the ones provided in the CREL.

Home page:

MAAS-WP7-D7.3D4.5 Page 29 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 12: UX design for Home page of the TC Web Registration:

Figure 13: UX design for user registration in the TC Web

User profile and preferences:

MAAS-WP7-D7.3D4.5 Page 30 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 14: UX design to manage user profile and preferences in the TC Web

Trip searching and results:

Figure 15: UX design for trip searching in the TC Web

MAAS-WP7-D7.3D4.5 Page 31 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Selection of ancillaries:

Figure 16: UX design to select ancillaries in the TC Web Booking:

Figure 17: UX design to book a trip in the TC Web

MAAS-WP7-D7.3D4.5 Page 32 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Payment:

Figure 18: UX design for user payment in the TC Web

Cancellation:

Figure 19: UX design for cancellation in the TC Web

MAAS-WP7-D7.3D4.5 Page 33 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

2.9.1.2 Implemented screens As previously indicated, for the CREL the implementation includes the following: Registration, login and preferences management. In the first release, the UX design has been taken as a reference, but the emphasis was made in the connection of this new front end with the existing backend of the CW.

Home Page:

This is the main page, in which the user can select the language and access the Login and Registration functionalities (top right). The page has been designed also including a quick link to the functionality of creating new trips and will show the list of planned trips, as both aspects were considered the most relevant ones for the user during the UX phase.

Figure 20: Home page of the TC Web

Registration:

In the registration screen, users are requested a minimum set of information to create a new user in the ecosystem. Once introduced, the information is sent to the CW associated to the new user. The

MAAS-WP7-D7.3D4.5 Page 34 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

screen also contemplates the possibility to register via an existing account (Google, Facebook) as it is done currently on other platforms, although the functionality is not enabled at this moment.

A two -factor registration mechanism is proposed to validate the user, commonly used on other platforms, which is based on using the phone number to send a code via SMS to validate the user.

Figure 21: Registration screen in the TC Web

Login:

The Login screen is a simple screen that allows including the user and th password. It is connected to the CW.

MAAS-WP7-D7.3D4.5 Page 35 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 22: Login screen in the TC Web Preferences:

Once logged in, at the top right hand, the users will see several buttons for direct access: one for the shopping cart, another one for alarms, and a third one for the user profile (in which the users can have their own personal photo or avatar).

Figure 23: Direct access buttons in the TC Web (top right)

By clicking on the user photo, the users will see a screen (Figure 24) with their profile information, including personal data, billing details, travel documents info, means of payment etc.). They can also change their preferences from there (Figure 25). The current implementation for preferences follows the same interface used in the TC app, which might be reviewed in the next release.

MAAS-WP7-D7.3D4.5 Page 36 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 24: Screen to manage personal data in the TC Web

Figure 25: Screen to manage preferences in the TC Web

MAAS-WP7-D7.3D4.5 Page 37 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Reference to API description The Web Portal is accessible under this address: http://business.integration.indra.shift2railcloud.com:7070/movticketing/

From there it is possible to see the Home Page and the registration and login access buttons. To see the preferences screen, it is necessary to be registered previously.

The complete documentation of the CW services, used by the TC Web, are accessible in : http://test.indra.shift2railcloud.com:8080/identity-1.0.1/swagger-ui.html http://test.indra.shift2railcloud.com:8080/preference-1.0.0/swagger-ui.html

Implementation choices For the Web Portal, a Framework based on Angular is proposed, which is an open-source front-end web framework. The objective is to have a modular framework following the same approach as the TC app.

Figure 26: Schema of the Angular architecture proposed for the TC Web

During the CREL, it has been identified which functionalities definitely be covered by the TC Web, among the ones already existing from ATTRACkTIVE in the TC app. These are the following:

 User management: registration, login, management of preferences.

 Shopping

 Ancillary

MAAS-WP7-D7.3D4.5 Page 38 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

 Booking

 Issuing

 After sales

 Allow anonymous user

Among them, the user management capabilities are provided within the scope of the CREL, while the others will be provided for the FREL. Trip Tracking and token management are not included in the list as they are currently under discussion, as they have dependencies with some modules that are normally related to phone identification.

Misalignments with specifications Not applicable for this component

3. TESTING AT COMPONENT LEVEL The aim of this first release is having a first version of the TC PA integrating the new components of MaaSive’s project. Through the specification, some components were identified to be implemented. Theses components were described earlier, and in order to have the different components ready to be integrated on the new Travel Companion they should be tested.

USE CASES TO BE VALIDATED Different use cases were identified during this first phase. Some of them are directly related to the component implemented for the CREL. The table below presents the ones related to the implemented components.

Use Case ID Use Case ID Name Related component Number UC_TD4.5_13 User has access to Travel Web Front end Companion functionalities through web portal UC_TD4.5_14 User can access several TC Web front end functionalities without being logged in the system UC_TD4.5_17 MAAS: User adds a Mobility Mobility packages Package to his profile management UC_TD4.5_19 Experience author develops a mixed Mixed Reality Composer reality experience UC_TD4.5_20 Experience author publishes a mixed LBE Publisher reality experience

MAAS-WP7-D7.3D4.5 Page 39 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

UC_TD4.5_21 Traveler starts an experience on a Experience engine mixed reality device from the personal application

DEPENDENCIES The Travel companion is deeply dependent to the different TDs. Then, the testing and integration of the present components are also dependent to these TDs.

Figure 27: TC interaction with other TDS

TESTING TOOLS During our implementation, the components were tested in order to be implemented on the Travel Companion. This implies the use of special testing software for this integration step.

The testing software used includes:

 SOAPUI – Desktop tool, which allows creating projects using different protocols (SOAP and REST) for automated functional, regression, and load tests based on Web services. In a single test environment, it provides complete test coverage (e.g., a test case, which concatenates different calls among which parameters should be reused, could be created). In addition, it allows simulating needed parts to complete the test and export the projects for sharing them.

 POSTMAN – Desktop and web tool which allows to interact with HTTP APIs and to automate tests. The request GUI is friendly and intuitive. Adding the URL to call, selecting the operation to perform, adding the header parameters and the body if needed, the request is created and the response will be received as JSON format. It allows configuring complex calls with environment variables or pre-request scripts and configuring the conditions that the response should achieve to consider that the test passed.

 SwaggerUI – Web tool configuring from the source code, which provides a GUI with the exposed services and the fields to fill. It also allows executing the call and retrieving the answer. It is compatible only with REST for the moment.

MAAS-WP7-D7.3D4.5 Page 40 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

 Simulation App (Android Studio) – IDE (Integrated Development Environment) for developing mobile applications, which allows executing a virtual simulator for a device with the desired Android version. In addition, it allows developing and debugging the possible found issues during the application execution. This tool is useful for testing the mobile components of the projects but taking into account that they should be tested after in a real device to consider the component ready.

 Git: In order to plan the successive integration windows with the available version of the modules, a specific versioning control system “GitLAB” was established. By having access to the GIT, the partners import their modules when ready.

 Jenkins: A continuous build is performed using Jenkins, which is a continuous integration tool.

 Others: along the project, new tools can be identified to accelerate and/or improve the testing methodology.

Based on the work carried out within ATTRACkTIVE, the three environments for testing are still used. The first one is used for development, the second one to test integration, and the third one to have a stable version.

TESTING PROCEDURE The testing procedure for MaaSive is based on the work carried out for Cohesive and ATTRACkTIVE. This testing procedure implies that each partner provides its contribution by testing his components in advance to be ready before the integration. Every module developed is tested separately using a test protocol before the integration. When ready all modules will then be integrated. This process based on a continuous testing platforms, enables to have frequent releases.

This work is carried out through MANTIS, different tickets were created for the test of the different components independently. When the components are ready, the MANTIS tickets related to the components are tested.

MAAS-WP7-D7.3D4.5 Page 41 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

4. TEST CASE DESCRIPTIONS

FRAMEWORK The Framework gives the method to set up the Travel Companion Personal Application. It defines how libraries have to be build and how these libraries can interact with each other. While testing a specific library the Framework is implicitly tested.

Test 1 Goal for this test is to assure that a Travel Companion Personal Application is running and is ready to be used.

Pre-requisites:

 Mobile device  All libraries that have to be integrated  System to download the TC PA to the mobile device

Test steps:

 Compile a new version; compiler lists no errors  Download the new version to the mobile device  Start the application

EMBODIMENT MANAGEMENT The goal of the test is to demonstrate the new functionality implemented for embodiment management and which will be the result for the user.

Test 1- display the valid token Test the functionality to display the valid token for the current segment based on Logical Position

Pre-requisites:

 The user should be logged in  The user should have booked and issued a trip  The user should be at a time of the day contained in the planned trip

Test steps:

 Before the next travel episode, the app will show the token, indicating the name of the “Next access gate”, meaning the station in which the token should be used to validate. (Figure 28)

MAAS-WP7-D7.3D4.5 Page 42 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 28: Token activated for use at “Next Access Gate”

MOBILITY PACKAGES MANAGEMENT The goal of the tests is to demonstrate the new functionality implemented for Mobility Packages management and which will be the result for the user.

Test 1- scanning physical travel cards This present test, aims to test the functionality for scanning physical travel cards.

Pre-requisites:

 The phone should have a camera  The user should be logged-in and access the “Tariffs” section  The travel card should be on the list offered by the TC

Test steps:

 Scan physical card  Card information will be gathered and shown in the screen (Figure 29)

MAAS-WP7-D7.3D4.5 Page 43 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 29: Result of scanning a card

MIXED REALITY ENGINE The test of this component allows us to ensure that the experiences created for the traveller could run on the new devices. It also aims to check that the experiences related to these new devices could be watched and launched through the TC PA.

MAAS-WP7-D7.3D4.5 Page 44 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 30: Process of how to start the experience on the Glasses The work is carried out within Android Studio and requests these elements

 Pre-requisites: o Android device o Personal application installed o Experiences installed o MR Device connected

Test 1- MR experiences on the devices  Test steps: o Start the personal application o Select the “Experience for me” menu to display the available experiences. o Check the experiences listed o The list of available experiences should be filtered w.r.t. the context of the user (i.e. geolocation) o Check that the Mixed reality experiences related to the connected device are displayed  Results:

Date of test Expected Result Observed Result

02-13/12/2019 Successful start of the Ok. experience from the list menu. Figure 30

Test 2- Run the experiences on the devices  Test steps: o Start the personal application

MAAS-WP7-D7.3D4.5 Page 45 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

o Select the “Experience for me menu” to display the available experiences. o Press and select the test Experience. o Press the start menu to begin the experience o Check that the experience runs on the mixed reality devices  Results:

Date of test Expected Result Observed Result

02-13/12/2019 The experience test runs on Ok. the HoloLens. Figure 30

MIXED REALITY COMPOSER The mixed reality composer is based on the LBE editor used for ATTRACkTIVE. These developments are currently working following Agile Sprints.

In this scope, there is a:

 Continuous build for the LBE Editor and the integrated Mixed Reality Composer. A snapshot of a daily build report is visible in Figure 31.  Everyday tests of the Mixed Reality Composer functionalities. A snapshot of the test result is visible in Figure 32 and Figure 33;

 Pre-requisites: o Windows based desktop computer o Android SDK o Android NDK o Android Tools (ADB)

MAAS-WP7-D7.3D4.5 Page 46 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 31: A snapshot of a daily build report.

Test 1- Automatic Testing of the MIXED REALITY COMPOSER: The Authoring tool is a complete creation kit, which leverages the technological burdens for geo- based authors and is able to publish on an Android device. A dedicated PC executes this test each day to ensure there is no regression.

 Test steps:

Using an automated procedure, the LBE Editor continuous testing is achieved each day as follows:

o Installation of the latest LBE Editor using the daily generated installer package o Opening of a validation project . Including all blocks developed for Mixed Reality, o Extracting the validation project scenario on the desktop device . Measuring at key moments performance indication . Capturing at key moments the visual rendering of the screen o Installing the experience on the mobile device and the Mixed reality device o Extracting the validation project scenario on the Mixed reality device . Measuring at key moments performance indication . Capturing at key moments the visual rendering of the screen o Closing the validation project on the Mixed reality device and the desktop device o Comparing performance and visual results  Generation of a report diffused to the validation team

MAAS-WP7-D7.3D4.5 Page 47 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 32: A snapshot of the Mixed Reality Composer through the LBE editor daily test report

Figure 33: A snapshot of the MR composer within the LBE editor daily test result report.  Results:

Date of test Expected Result Observed Result

02-13/12/2019 No error when compilation Ok. and testing.  return code 0 means no error. Figure 32

MAAS-WP7-D7.3D4.5 Page 48 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Test 2 - Manual Testing of the MR composer: Additionally to ensure the validity of the publication process into the TC, a manual test is performed.

 Test steps: o Start the LBE editor. o Press to import the test project. o Test the experience on the desktop device. o Press to publish the experience on the mixed reality device.

 Results:

Date of test Expected Result Observed Result

02-13/12/2019 The LBE integrating the MR Ok. composer successfully working

LBE LAUNCHER MODULE The launcher module is based on the Launcher of the ATTRACkTIVE project aiming to start the experience selected by the user. The new behaviour of this module is related to the use of new devices. For the present project, the launcher should be able to launch the experience on the specified glasses “the HoloLens”

 Pre-requisites: o Android device or android emulator o TC-PA application installed on mobile device o Experiences installed

Test 1-Launch Experiences:  Test steps: o Start the personal application o Select the “Experience for me menu” to display the available experiences. o Press and select the desired Experience. o Check the experiences listed according to the devices o Press the start menu to begin the experience

 Results:

Date of test Expected Result Observed Result

02-13/12/2019 Successful start of the Ok. experience from the list menu on the HoloLens.

MAAS-WP7-D7.3D4.5 Page 49 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Test 2-Stop Experience:  Test steps: o Start the personal application o Select the “Experience for me menu” to display the available experiences. o Press and select the desired Experience. o Check the experiences listed according to the devices o Press the start menu to begin the experience o Press the stop menu to stop the experience

 Results:

Date of test Expected Result Observed Result

02-13/12/2019 Successful stop of the Ok. experience from the list menu on the HoloLens.

LBE WATCHER MODULE The LBE watcher enables the launcher to display the available experiences when appropriate based on ATTRACkTIVE one, it supports new mixed reality devices.

 Pre-requisites: o Android device or android emulator o TC-PA application installed on mobile device

Test 1- Test the watcher module: To ensure the proper functioning of the experiences display process for the travellers the watcher should be tested according to the different conditions preseted by the author.

MAAS-WP7-D7.3D4.5 Page 50 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

(a) (b)

Figure 34: Screenshot of the experience’s list regarding the different devices (a): the glasses, (b): the phone  Test steps: o Start the personal application o Select the Experience for me menu to display the available experiences. o The list of available experiences should be filtered w.r.t. the context of the user (i.e. geolocation, devices connected to the PA)

 Results:

Date of test Expected Result Observed Result

02-13/12/2019 A list of experiences related to Ok. each devices. The two experiences Figure 34 developed within ATTRACkTIVE for the phone device and a test experience for the connected HoloLens.

WEB FRONT END The goal of the tests is to demonstrate the functionalities implemented for the TC Web portal and which will be the result for the user.

MAAS-WP7-D7.3D4.5 Page 51 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Test 1-Test user registration The present test allows testing user registration.

Test steps:

 New user access the TC Web Portal  Select register option  Includes the personal data (Figure 35)

Figure 35: Introduction of user info for registration Results:

Date of test Expected Result Observed Result

20/12/2019 Successful registration Ok. message should appear See Figure 36

Figure 36: Success message

Test 2-Test user Login The present test allows testing user login.

MAAS-WP7-D7.3D4.5 Page 52 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Pre-requisites:

 Have a user account

Test steps:

 Existing user access the TC Web Portal  Selects Login option  Includes the requested data (Figure 37)

Figure 37: Introduction of user info for login Results:

Date of test Expected Result Observed Result

20/12/2019 Successful Login message Ok. should appear. Now it should be possible to access to the See Figure 32 user profile and preferences

MAAS-WP7-D7.3D4.5 Page 53 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Figure 38: Success message

Test 3-Test Preferences screen The present test, allows testing the preferences screen.

Pre-requisites:

 Have a user account  Be logged in the system

Test steps:

 User clicks in the photo or avatar (Figure 39)  Selects the Preferences screen in the menu and changes the preferences (Figure 40)  Saves preferences.

Figure 39: User Photo/avatar, from which the preferences are accessed

Figure 40: Change preferences

MAAS-WP7-D7.3D4.5 Page 54 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Results:

Date of test Expected Result Observed Result

20/12/2019 Successful message should Ok. appear. User should be able to see the selected See Figure 35 preferences at any time

Figure 41: Success message

5. TEST REPORTS This section summarise the different tests presented in the test case description part of the document and presents for each component tested the responsible and the obtained results.

During this first phase of work, we carried out tests of each of the components in order to verify their behaviour and correct functioning. As described above, all the components have been implemented and tested by each of the partners involved as shown in the table below.

Test Who’s performing Results

Framework running giving HACON OK internal access to all modules

Display the valid token INDRA OK

Scanning physical travel cards INDRA OK

MR experience on the device DIGINEXT OK

Run the experiences on the DIGINEXT OK devices

Automatic tested DIGINEXT OK

Manual testing DIGINEXT OK

Launch experience DIGINEXT OK

Test the watcher module DIGINEXT OK

MAAS-WP7-D7.3D4.5 Page 55 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

Test user registration INDRA OK

Test user logging INDRA OK

Test preferences screen INDRA OK

6. SUMMARY AND RECOMMENDATIONS FOR NEXT STEPS This first release aims to implement some of the components that will integrate the new Travel Companion version.

As presented in the Specification and on the Implementation reports this new TC integrates new concepts such as the MaaS as well as group travelling services.

For this Release, the focus has been laid on providing evolution of some modules, the framework the watcher, the launcher as well as the implementation of additional modules such as the web front end, the mixed reality engine and composer, the embodiment manager and the mobility package manager.

This document summarise the work achieved to implement the component specified within the travel companion specification, specially scheduled for the CREL. This Release follow the work plan and meets the requirements and system specifications defined in the Core Release3.

Within the different sections, the implementation and test process used to consolidate and implement the components are presented. The successive sections, gave an overview of the implementation carried out and then test case descriptions and progress for each component.

Using a common development framework, a collaborative repository as well as common testing and specification tools (Wiki, Mantis, Capella…), all the created modules are tested at component level and validated to be integrated together for the next release.

This future work will hold the implementation of the remaining components foreseen for the final Travel Companion release. Improvements or adaptations could then be considered.

3 WP

MAAS-WP7-D7.3D4.5 Page 56 of 57 2020/12/2019

H2020 – Contract

No 826385 – MaaSive

End of document

MAAS-WP7-D7.3D4.5 Page 57 of 57 2020/12/2019