MOBiNET DEL D5.14 PilotNorthDenmark v4.0 20170602 · from drawing for simplification). ... in UML as an “actor”) and a system, ... D51.2 5.2 Validation and assessment plan

Work package: WP5

Version number: 4

Dissemination level: PU

Date: 02/06/2017

7th RTD Framework Programme Directorate General for Communications Networks, Content & Technology Cooperative Systems for energy efficient and sustainable mobility (FP7-ICT-2011-6.7) Contract Type: Collaborative project Grant agreement no.: 318485

D5.14 MOBiNET on Pilot site North Denmark Region


02/06/2017 Page 2 of 55 Version 4.0

Version Control Version history

Version Date Main author Summary of changes

0.1 11-04-2014 Jens Mogensen First draft

1.1 01-05-2014 Jens Mogensen Second draft

2.01 26-11-2015 Jens Mogensen Updated version

3.0 18-05-2017 Jens Mogensen Updated version

4.0 31-05-2017 Jens Mogensen Final

Name Date

Prepared Jens Mogensen (NDR) 30/05/2017

Reviewed Lars Mikkelsen (AAU) 01/06/2017

Authorised Maxime Flament 02/06/2017

Circulation

Recipient Date of submission

European Commission 02/06/2017

Project partners 02/06/2017

Authors

Jens Mogensen (NDR), Jesper Holgersen (Gatehouse), Lars Mikkelsen (AAU).


02/06/2017 Page 3 of 55 Version 4.0

Table of contents Table of Figures .................................................................................... 5

Table of Tables ..................................................................................... 6

Abbreviations and definitions ................................................................ 7

Executive Summary .............................................................................. 8

1. Introduction ..................................................................................... 9

1.1. Purpose, scope and target audience of this report ....................................... 9

1.2. Structure of the document ............................................................................ 9

1.3. Related MOBiNET documents ...................................................................... 9

2. Test site ......................................................................................... 10

2.1. Description ...................................................................................................10

2.1.1. Partners and organization ................................................................................ 13

2.2. Deployed services .......................................................................................13

2.2.1. B2B Parking data service ................................................................................. 14

2.2.2. B2C Parking service ......................................................................................... 14

2.2.3. Transferring the service to Trikala .................................................................... 20

2.3. Architecture .................................................................................................22

2.3.1. RTTI ................................................................................................................. 25

2.3.2. Status on North Denmark Implementation and Validation ............................... 26

3. Methodology .................................................................................. 30

3.1. Test responsibilities across the Sub Projects ..............................................30

3.2. Methodology of the North Denmark Pilot site ..............................................31

4. Validation ...................................................................................... 33

4.1. Validation plans and guidelines ...................................................................33

4.2. Results and recommendations after validation R4.0....................................34

5. Conclusions and recommendations .............................................. 35

Appendix I: Validation Test cases, scenarios and results ................... 36

Validation Scenarios .............................................................................................36

Create MOBiNET OpenID and Manage identity ........................................................... 36

Publish and Manage B2B service ................................................................................. 37

Search and Display B2B service ................................................................................... 41

Discovery and Use of App .....................................................................................43

REST API of Service Directory ..................................................................................... 46


02/06/2017 Page 4 of 55 Version 4.0

Authentication API ........................................................................................................ 47

Create Business Identity ............................................................................................... 47

Create User Identity ...................................................................................................... 48

Publish B2B Service ..................................................................................................... 49

Search for B2B Service as a Service Provider ............................................................. 51

Search for B2B Service as an App ............................................................................... 52

Publish B2C App ........................................................................................................... 53

Search for App .............................................................................................................. 55


02/06/2017 Page 5 of 55 Version 4.0

Table of Figures Figure 1 The North Denmark Pilot site ..................................................................................................... 10 Figure 2 ITS system in the Highway tunnel .............................................................................................. 11 Figure 3 Travel time information and dynamic speed limitation as Part of the Aalborg ITS Highway system. ..................................................................................................................................................... 11 Figure 4 ITS for cyclists with speed measurement and calculated ETA to the University ........................ 12 Figure 5 intensive use of ITS in Public Transport in the Region ............................................................... 12 Figure 6 Route guidance to free parking space nearest to destination .................................................... 16 Figure 7 information to car driver, that a parking payment is initiated. ..................................................... 17 Figure 8 Parking instances in the back offices Parking Manager ............................................................. 18 Figure 9 Example of QR label for car ....................................................................................................... 19 Figure 10 Sequence diagram for a B2B parking session ......................................................................... 21 Figure 11 Architecture and flow for the parking services .......................................................................... 22 Figure 12 Parking Service Provider which is not MOBiNET enabled ....................................................... 23 Figure 13 Parking service providers whose services are MOBiNET enabled (parking attendant excluded from drawing for simplification). ................................................................................................................ 24 Figure 14 Parking service use of MOBiNET Platform components .......................................................... 25 Figure 15 Real Time traffic information in Aalborg ................................................................................... 26 Figure 16 MOBiNET development time processes and relationships, taken from (D51.1) ...................... 31


02/06/2017 Page 6 of 55 Version 4.0

Table of Tables Table 1 Related MOBiNET documents ...................................................................................................... 9 Table 2 Contact persons for the North Denmark Pilot Site ....................................................................... 13 Table 3 List of Parking service modules ................................................................................................... 21 Table 4 Overview over implementation and validation in North Denmark, in different releases ............... 26 Table 5 Overview over use of MOBiNET components in different releases ............................................. 29 Table 6 division of responsibility for verification and validation ................................................................ 31


02/06/2017 Page 7 of 55 Version 4.0

Abbreviations and definitions

Abbreviation Definition

MMTA Multi Modal Travel Assistant

CA Communication Agent

CM Communication Manager

HMI Human Machine Interface

OBU On-board Unit

RSU Road Side Unit

LDM Local Dynamic Map

SDK Software Development Kit

GLOSA Green Light Optimal Speed Advice.

VAP Validation and Assessment Plan

RTTI Real Time Traffic Information

PT Public Transport

TERMS DEFINITION

Component A software component in the MOBiNET platform. For instance, the service directory or the dashboard.

Parking data service

Parking data service. One of the services developed by the North Denmark pilot.

Parking service Parking service. One of the services developed by the North Denmark pilot.

RTTI Real Time Traffic Information. A service developed by Helmond and transferred to the North Denmark Site

Service Each of the existing or developed mobility solutions adapted and combined into the MOBiNET platform. The services in Release 1 include: GLOSA, MMTA or UBI

Use case A use case is a list of steps, typically defining interactions between a role (known in UML as an “actor”) and a system, to achieve a goal. The actor can be a human or an external system.

Validation The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.

Verification The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.


02/06/2017 Page 8 of 55 Version 4.0

Executive Summary This is the MOBiNET implementation and Validation Report for the North Denmark Pilot site. It reports on the implementation of services in the North Denmark Pilot, and on plan and results for validation of the MOBiNET platform Release 4.0.

With the purpose of setting up requirements for the development of the MOBiNET system, and for testing and validating the functionality of the different versions of the developed MOBiNET System, the North Denmark Pilot site has developed and implemented two parking services; validated the MOBiNET components by use of these services, and thus given input for next versions, and, by implementing the Danish parking service in Trikala and the RTTI services from Helmond in Denmark, demonstrated how easily MOBiNET services can be transferred to other countries or made Europe wide, when using the MOBiNET platform.

The two Parking services have been running in Denmark since April 2015 for a group of 30 testusers. The functionality was almost complete from the first release, but has been supplemented as more MOBiNET components, as Identity Manager and Billing have been released.

The Parking service was transferred to Trikala in release 3, and a clearing/billing system between the two parking service suppliers was established, using the MOBiNET Identity Manager and the MOBiNET Billing.

Before Release 4 the Helmond Real Time Traffic Information service was connected to a datastream with Danish traffic data from the Danish Road Directorate, and it was demonstrated, that the RTTI service worked in North Denmark thanks to the MOBiNET platform.


02/06/2017 Page 9 of 55 Version 4.0

1. Introduction

1.1. Purpose, scope and target audience of this report

The purpose of this document is to present the pilot implementation in North Denmark covering the local development of services and how these services utilizes the MOBiNET platform; to define the validation framework for the North Denmark pilot site, and to report on the validation results.

1.2. Structure of the document

Chapter 2 describes the North Denmark Pilot site and the implementation of the usecases in North Denmark.

Chapter 3 presents the general methodology of the verification and validation process.

The set-up for the validation tests is described in Chapter 4. In addition, the results and recommendations after validation of the MOBiNET release 4 are listed in this chapter.

In Chapter 5 the general conclusions coming from the validation activities on release 4 and the Lessons learned are presented.

1.3. Related MOBiNET documents

Table 1 Related MOBiNET documents

Finalised MOBiNET deliverables

Reference Document

MOBiNET DoW

DOW MOBiNET (318485) Amendment3 2016-07-15

D21.1 2.1 Use case scenarios selection and preliminary requirements definition

D52.3 5.3 Guidelines and trial plans for pilot validation

D21.2.1 2.2a Final MOBiNET requirements (release 1)

D51.2 5.2 Validation and assessment plan

D31.3.1 3.3a Architecture refinement and integration (release 1)

D52.6.1 5.6a Interim platform, pilot and business validation results (includes pilot status reports and validation results)

D52.7.1 5.7a Interim integrated analysis of platform & pilots validation

D3.19 3.19 Architecture refinement and integration (final)

D3.24 3.24 Service Development Kit (final)

D63.6.1 6.6a Non-technical requirements (release 1)

D63.6.2 6.6b Non-technical requirements (release 2)


02/06/2017 Page 10 of 55 Version 4.0

2. Test site

2.1. Description

The North Denmark pilot site consists of the North Denmark Region, which is outlined by the three coordinates: N 56° 48.’, E 8° 10.5’ - N 57° 44.5', E 10° 37.5' - N 57° 44.0', E 10° 37.5'

The center of the region is the City of Aalborg. The demonstration is centered around Aalborg and on the connecting road network. See Figure 1. One of the reasons for this is that the City of Aalborg yet is the only city in the region capable of delivering the real-time data for number of free parking slots, required in the Parking use case.

Figure 1 The North Denmark Pilot site

The North Denmark Region covers 7.933 km² and has 579,829 inhabitants. The region has 227 km highway and 11,615 km other roads.

The North Denmark Region is the default leading ITS region in Denmark, with a long tradition for an intensive ITS cooperation between the Region, the City of Aalborg, the Public Transport Authority of North Denmark, the Police and the Danish Road Directorate. The project expects to benefit from this both in terms of support from transport users and in terms of use of data, systems and experiences from the ITS establishment in the area

ITS is widely used in the region including a tunnel-control system, dynamic parking information system, Adaptive Signal Control System, traffic information systems, roadside cameras for monitoring and traffic information, cameras with ANPR system for congestion monitoring, Bluetooth based system for congestion monitoring, Real time Information systems with OBUs in all Public Transport buses, GPS based Public Transport prioritisation in all major intersections, etc.


02/06/2017 Page 11 of 55 Version 4.0

Figure 2 ITS system in the Highway tunnel

Figure 3 Travel time information and dynamic speed limitation as Part of the Aalborg ITS Highway system.


02/06/2017 Page 12 of 55 Version 4.0

Figure 4 ITS for cyclists with speed measurement and calculated ETA to the University

Figure 5 intensive use of ITS in Public Transport in the Region


02/06/2017 Page 13 of 55 Version 4.0

2.1.1. Partners and organization

Three organizations are participating as partners in the North Denmark Pilot, and the pilot is supported by more shareholders.

The partners are The University of Aalborg (AAU), Gatehouse, and the North Denmark Region.

The Shareholders are the Danish bank sectors payment association, Nets, The Danish Road Directorate, the City of Aalborg, and the North Denmark Public Transport Authority, NT.

During the project period, the partner’s cooperation around the pilot project was coordinated on meetings in the working group.

Relations to shareholders have been taken bilaterally, with the possibility for joint meetings, if beneficial for the project.

A test-user community is established, for testing the MOBiNET systems through the use-cases implemented in the pilot site. The test-user community consists of 30 test users, and have been created from selected participants in a previous ITS project.

Table 2 Contact persons for the North Denmark Pilot Site

Role Name Email Phone

Site leader. North Denmark Region

Jens Mogensen [email protected] +45 2941 8499

AAU Rasmus Løvenstein Olsen

Lars Mikkelsen

[email protected]

[email protected]

+45 2349 0047

GateHouse Jesper Holgersen [email protected] +45 9932 4057

2.2. Deployed services

The purpose for the North Denmark Pilot for deploying services in the MOBiNET project, has not been the functionality of the service themselves, but to support development and testing of the MOBiNET platform.

The purposes have been:

based on the services, giving requirements for the development of the MOBiNET components, testing the functionality of the different versions of the developed MOBiNET System validating the MOBiNET components by use of the developed services giving input for next versions by transferring services developed in Denmark to Trikala and service developed in Helmond to

Denmark, to demonstrate how easily MOBiNET services can be made Europe wide, when using the MOBiNET platform.

The North Denmark Pilot has developed two services. A B2B Parking Data Service and a B2C Parking Service with automatic parking payment and additional functions as for example ‘Find nearest free parking slot’. The two services could have been implemented as one integrated service, but to test all the


02/06/2017 Page 14 of 55 Version 4.0

MOBiNET functionalities, and to demonstrate the benefit of using the MOBiNET platform when developing ITS services, the parking services are implemented as two separate services. The B2C Parking Service was developed in two steps: First a B2C Parking Service with automatic parking payment for one parking service provider, using the MOBiNET components available at the time of development (e.g. Service Directory).

Thereafter the B2C service was extended with B2B Parking functionality for more simultaneous parking service providers and thereby adding the usage of additional MOBiNET components, e.g. Billing and Identity Management, enabling further possibilities for both business and end users.

The service is in real use test by 30 users in the Nord Denmark Pilot. The end user test tests and demonstrates that the services are working as intended.

As described later, the Parking services is transferred to test site Trikala to demonstrate the benefit of using MOBiNET as platform.

2.2.1. B2B Parking data service

This service collects real-time parking information from several car parks and makes them available – through the service directory - for B2C services for example for offering guidance to nearest free car park in real-time. The services include a broader range of information for each car park, such as number of free parking slots, number of parking slots for disabled, and number of charging points for electrical vehicles. The information can be used for services as Find Nearest EV Charging Point etc.

The service can also be used as a B2B service delivering data to other B2C Parking Service so that customer from one parking provider can park at the parking lots from other parking providers as long as they support the MOBiNET Parking API, thus enabling more customers for the parking providers.

The service is general and open for addition of real-time data from all cities/countries.

At the present, real-time information dataset is available for 10 car parks – private and city-owned - in the City of Aalborg, and for carparks in Trikala.

In a future MOBiNET world, the business case for the supplier of this service will be, to be a data integrator and provider, acting as a link between the car park owners, who possesses the data and wishes to publish them, and the B2C service suppliers whose business case is utilizing these data in services sold to end customers.

As a part of the CIVITAS project ARCHIMEDES, the City of Aalborg developed two webservices containing semi-static data on car parks and dynamic real-time data on occupancy rate for the car parks. Via a REST API, developed in the MOBiNET project by Gatehouse, data from these webservices were the first parking data made available for all B2B and B2C service providers via the MOBiCENTRE.

2.2.2. B2C Parking service

The end-user, the car driver, needs a parking service that can support him during his parking. Most importantly, he needs an automatic parking payment function, which knows the local parking rules and fees and can take over the responsibility for the payment, thus releasing him for the trouble of paying each time, and the risk of a parking fine if he misses. When subscribing to the right service all the user sees is a deduction on his bank account once a month.


02/06/2017 Page 15 of 55 Version 4.0

But what the car driver really needs, is a generic parking service that he can use, even when he is not in his own area or country. This service is the MOBiNET B2C Parking Service. The car driver finds it in the NDR Parking app by searching the Service Directory for nearby MOBiNET Parking services.

The parking service features a range of parking related functions, available in an app developed for Android smartphones, utilizing a back office server for parking, payment and user management. The app can be found by searching the Google Play services or via the MOBiAgent app.

The parking service description has initially been uploaded by the service provider to the MOBiNET service directory using the MOBiNET Dashboard. Through the Service Directory, the Parking Service app then discovers such real-time parking data services. The discovery utilizes the MOBiNET functionality to select the geographically relevant service, based on the cars position.

The parking service offers four different parking features to the end user:

1) Route Guidance to nearest parking lot with free parking spaces. 2) Automatic GPS based parking initiation and completion, incl. payment. 3) Time-limited parking assistance. 4) Find my parked car.

Route Guidance to nearest free parking lot with free parking spaces

When approaching his destination, the user activates his MOBiNET enabled app supporting the MOBiNET Parking Services and chooses the Find Nearest Free Parking Bay Function. He can choose, if he wants, to be guided to a parking lot with available space nearest to his present position, or nearest to the destination of his trip.

After choosing one of these alternatives, and based on the GPS position, the app first decides which parking data service in the MOBiNET Services Directory to request data from. Thereafter the Parking Services locates the right parking space by searching in the real time parking data stream, delivered by that Parking Data Service, and a normal route guidance display emerges on the smartphone, guiding the driver from his present position to the free parking space.


02/06/2017 Page 16 of 55 Version 4.0

Figure 6 Route guidance to free parking space nearest to destination

This function saves the car driver for both time and fuel costs by removing the need for driving around in the city searching for a free parking space. At the same time this function has environmental effect in that it reduces fuel consumption, congestion and emissions.

Automatic GPS based parking initiation and completion, incl. payment.

When arriving to a car park, the Pay my Parking Function in the MOBiNET Parking Service registers – using the units GPS - that the car is being parked on a payment car park and a payment is initiated in the services park Manager back-offices system – taking into account the specific price and payment rules for the car park, at this time of the day.


02/06/2017 Page 17 of 55 Version 4.0

Figure 7 information to car driver, that a parking payment is initiated.

For the service covering the Aalborg area the service further uses a map-matching function that analyses the car’s GPS track and compares it to the road network around the car park, thus making sure if the car is parked on, or not just outside, a parking space.

In the demonstration, the user has the possibility to cancel a parking, if he don’t want to park.

When the user collects his car the MOBiNET Parking System determines from the changing GPS position, that the parking is terminated – and the payment period is ended.

The fee for the parking is then calculated. In calculating the parking fee, the back offices Parking Manager takes into account variables such as the specific price and payment rules for this car park, at this time of this day. The price and rules information are delivered by the real time data services from the MOBiNET enabled Parking Data Services and can thus can change from day to day.

After the fee has been calculated, a payment request is initiated for that amount on the credit card associated with the registration number of the car. The payment is transferred from the end-uses credit card to the service providers’ account. At the end of the day or month, depending on the agreement with the carpark owner, the aggregated amount is transferred to the Carpark Owner, less an agreed services fee.


02/06/2017 Page 18 of 55 Version 4.0

Figure 8 Parking instances in the back offices Parking Manager

Time limited parking assistant

When approaching his destination, the MOBiNET Parking Services guides the user to a free parking bay along the pavement. The parking is free of charge, but the parking is limited to for example 2 hours. The Time Limited Parking Function in the MOBiNET Parking Services goes in action. The user does not realize that the MOBiNET function is supporting him, until he receives a Push messages saying, ‘The time limit on your parking is reached in 10 minutes’.

The 10 minutes warning time is variable, calculated from the time limit for the parking space. With a longer allowed parking time, a longer warning is given allowing you to get back to your car before the time limit is exceeded.

(Due to lack of real-time data on occupancy of pavement parking at present, some functions are limited in the demo-version)

Find my parked car

When a parking session is ongoing the Find my parked car service can give route guidance back to the parked car, based on the saved GPS position for the car, the persons current GPS position, and the route guidance tool.


02/06/2017 Page 19 of 55 Version 4.0

QR-code based parking control function

The last function is a QR-code parking control function. When registering as user of the MOBiNET Parking service the car owner receives a QR code label to stick on the front window of the car.

Figure 9 Example of QR label for car

When a parking attendant sees a parked car with a MOBiNET parking label, he reads the QR code with a standard QR reader in his smartphone. The QR code contains a link (URL) to the Parking Manager database and the registration number of the car. When getting a request for a URL the back offices will, based on the registration number and the information in the database, either have the parking attendant’s smartphone show the message: “Car number xxxx is paying for a parking on carpark xxxx. Parking was initiated at xxxx o’clock” or “Car number xxxx is not paying for a parking in the MOBiNET parking system”.

For security reasons the very first time a smartphone is used to contact the parking service, the parking attendant will be asked to key a password to access the parking service.


02/06/2017 Page 20 of 55 Version 4.0

2.2.3. Transferring the service to Trikala

By extending the initial release of the Parking Service with B2B functionality allowing the service to integrate parking services from more parking service providers at the same time, the end user gets access to a generic parking service that he can use, even when he is not in his own area or country. This was made possible after the release of the MOBiNET Billing component in R3.1, and by using the MOBiNET Identity Management it was made possible to control the B2B relationship.

As a proof of the MOBiNET concept, car parks in Trikala in Greece is now integrated into the parking service. After setting up a data service from Trikala, it only required a limited amount of effort to extend the B2C Real Time Parking service to Trikala and to let the system chose to use real time parking data from the Greek source when in Greece, to demonstrate the benefit of using MOBiNET in the implementation.

The core part of implementing the B2B use case was to publish the Greek data services in the Services Directory, and to employ the Identity Manager and Billing Manager to handle two business parties.

In the future the business case for the supplier of MOBiNET enables parking services will be to be a data integrator and provider. MOBiNET and the MOBiNET service directory will then act as a link between the car park owners, who possesses the data and wishes to publish them, and the B2C services suppliers whose business case is utilizing these data in services sold to end customers.

If the car owner is registered as a parking customer at another services supplier, as in this demonstration, a Danish car visiting Trikala or a Greek car visiting North Denmark, the following procedure is initiated:

When the Greek system registers that a customer in the Greek parking system is parking on a Danish payment car park, the Greek parking system registers this parking session and also notifies the Danish parking system (using its Business Identity in the MOBiNET Identity manager to identify itself to the Danish system) thus initiating a parking instance in the back offices system so a fee later can be calculated. Additionally, the Danish parking attendant’s validation function can see, that the parking is legitimate, just as if it was a Danish customer.

In this way the Greek system is prepared to receive a later billing request from the Danish system, or the Greek system can reject the parking, if needed, for example if the customer has outstanding debt to the Greek parking system.

When the parking has ended, the system at the Danish service provider calculates the fee, and asks the MOBINET Billing system to issue a clearing request (or send a bill) to the MOBiNET Business Identity of the Greek parking system, at the end of the day or months, whatever is agreed.

The Greek end-user pays the parking fee to his own services provider, as a part of his normal bill, in his normal way, and in his normal currency.


02/06/2017 Page 21 of 55 Version 4.0

Figure 10 Sequence diagram for a B2B parking session

Table 3 List of Parking service modules

Module Module description

BO_Map_GIS Back offices function managing GIS information on car parks, including the semi-static information on car parks from the Parking Data Service.

BO_Payment_cal Back offices function calculating the parking fee for a parking, based on payment session information from the Parking_Payment in the vehicle and fair information from BO_Map_GIS from the Parking Data Services interface.

BO_Clearing Backoffices function initiating a payment transfer from a MOBiNET users (vehicle owners) bank account to the car park owner.

Map_match_position In-vehicle function positioning the car based on GPS position and advanced map matching routines developed to the project.

Find_free_parking In-vehicle function localising the free parking slot nearest to destination or vehicle depending on user choice. Based on BO_Map_GIS and Map_match_position.

Route_guidance In-vehicle function guiding the driver to the parking slot identified through the Find_free_parking module. Implemented as a call to the vehicle units build in navigation function.

Parking_Payment Based on BO_Map_GIS and Map_match_position the function determines if the vehicle is on a payment car park and initiates and terminates a payment session.


02/06/2017 Page 22 of 55 Version 4.0

Time_Limited_Parking Based on BO_Map_GIS and Map_match_position the function determines if the vehicle is on a time limited car park and warns the user, before the time limitation is reached.

Find_parked_car Gives walking route guidance to the parked car based on vehicle position information from either Parking_Payment or Time_Limited_Parking, by call to the units build in navigation function.

QR_control Verifies if a parking payment is running by looking in the back offices database.

Initiate_roaming_parking Initiates a parking roaming when a car is parked outsides the area of the cars original Parking Services Provider

Billing Executes a billing and clearing process between two Parking Services Providers after the end of a roaming parking

2.3. Architecture

Figure 11 Architecture and flow for the parking services


02/06/2017 Page 23 of 55 Version 4.0

Figure 11 Architecture and flow for the parking services illustrates the architecture with MOBiNET for a setup including as well the B2B data service, the B2C end user services as an optional second B2C service utilizing the B2B data services.

The diagram is explained by the text in the previous sections.

A proprietary parking system would have the architecture in Figure 12:

Figure 12 Parking Service Provider which is not MOBiNET enabled

The system would be closed, and thus difficult to extend with more car parks or more parking providers.

In Figure 13 the Parking Services is made open by using the MOBiNET Platform. More parking service communicates, or cooperates, through the MOBiNET components. Consequently, the car user can seamless use his own parking services in foreign arears without doing anything actively himself.


02/06/2017 Page 24 of 55 Version 4.0

Figure 13 Parking service providers whose services are MOBiNET enabled (parking attendant excluded from drawing for simplification).

The important learning from the diagram, is the positioning of the MOBiNET system as the unifying element in the middle of the architecture.

The B2B Parking Data Service and the B2C Parking Service directly uses the following MOBiNET components:

– Identity Manager – Service Directory – Billing Component

Secondarily, the following MOBiNET components presents the service and app or is used for enabling the user of the components listed above:

– Dashboard – MobiAgent – SDK (for generating Service Description)


02/06/2017 Page 25 of 55 Version 4.0

Figure 14 Parking service use of MOBiNET Platform components

The SDK has been used for developing the service description.

The Dashboard has been used when testing and publishing the service.

Both services are published in the Services Directory to be accessed by other services or end-users.

Identity Manager is used when interacting with the system as identification in the billing transactions between the two Services Suppliers and between the Services Owners in Denmark and Greece.

Billing is used to create and administer the billing transactions between the two Services Providers in Denmark and Greece.

MOBiAGENT is used by the end-user to discover the parking services and apps.

2.3.1. RTTI

To demonstrate MOBiNET transferability the Real Time Traffic Information developed in Helmond, has been implemented in North Denmark.


02/06/2017 Page 26 of 55 Version 4.0

A Datex2 data stream containing information on road incidents and accidents in Aalborg from The Danish Road Authority has been made available for the RTTI service, and it has been demonstrated, that the RTTI service works in Denmark.

Below can be seen screen shots of the RTTI app, displaying traffic data from Aalborg.

Figure 15 Real Time traffic information in Aalborg

2.3.2. Status on North Denmark Implementation and Validation

The next table presents a compressed overview of the development and testing in the different releases in the North Denmark Pilot Site.

Table 4 Overview over implementation and validation in North Denmark, in different releases

NORTH DENMARK

Service(s) R 2.0 Parking services: B2B Parking data service and B2C Parking service

N/A

R 2.1 Parking services: B2B Parking data service and B2C Parking service

N/A


N/A


RTTI


RTTI


02/06/2017 Page 27 of 55 Version 4.0

Availability of Architecture definition

R 2.0 Figure 11 Architecture and flow for the parking services

Architecture is the same described by Pilot Helmond, since the RTTI service has been transferred to North Denmark

R 2.1

R 3.0

R.3.1

Services modules to be used

R 2.0 BO_Map_GIS

BO_Payment_cal

BO_Clearing

Map_match_position

Find_free_parking

Route_guidance

Parking_Payment

Time_Limited_Parking

Find_parked_car

N/A

R 2.1 BO_Map_GIS

BO_Payment_cal

BO_Clearing

Map_match_position

Find_free_parking

Route_guidance

Parking_Payment


Find_parked_car

N/A

R 3.0 BO_Map_GIS

BO_Payment_cal

BO_Clearing

Map_match_position

Find_free_parking

Route_guidance

Parking_Payment


Find_parked_car

N/A

R 3.1 BO_Map_GIS

BO_Payment_cal

BO_Clearing

Map_match_position

RTTI_APP: Application

RTTI_SP: Service provider

RTTI_CS: Content server


02/06/2017 Page 28 of 55 Version 4.0

Find_free_parking

Route_guidance

Parking_Payment


Find_parked_car

Find_local_parking_service

Initiate_roaming_parking

Billing

R 4.0 BO_Map_GIS

BO_Payment_cal

BO_Clearing

Map_match_position

Find_free_parking

Route_guidance

Parking_Payment


Find_parked_car

Find_local_parking_service

Initiate_roaming_parking

Billing

RTTI_APP: Application

RTTI_SP: Service provider

RTTI_CS: Content server

Definition of the validation scenarios

R 2.0 Create MOBiNET OpenID and Manage identity (VS_AAL_CMID_SP_01)

Publish and Manage B2B service (VS_AAL_PMS_SP_01)

Search and Display B2B service (VS_AAL_SDS_SP_01)

Discovery and Use of App (VS_AAL_DUA_EU_01)

REST API of Service Directory (VS_AAL_REST_EU_01)

Authentication API (VS_AAL_AAPI_EU_01)

Billing (VS_AAL_ AAPI_EU_01)

R 2.1

R 3.0

R 3.1

MOBiNET components to be used for validation purpose

R 2.0 MOBiAGENT

Service Directory

SDK – Software Development Kit

Dashboard

N/A

R 2.1 MOBiAGENT

Service Directory


Dashboard

N/A

R 3.0 MOBiAGENT

Service Directory

N/A


02/06/2017 Page 29 of 55 Version 4.0


Identity Manager

Dashboard

R 3.1 MOBiAGENT

Service Directory


Identity Manager

Dashboard

Billing

MOBiAGENT

Service Directory


Dashboard

CM/CA

R 4.0 MOBiAGENT

Service Directory


Identity Manager

Dashboard

Billing

MOBiAGENT

Service Directory


Dashboard

CM/CA

Validation status R 2.0 Done N/A

R 2.1 Done N/A

R 3.0 Done N/A

R 3.1 Done Done

R 4.0 Done Done

Error! Reference source not found. presents an overview of use of different MOBiNET Components in different releases in the North Denmark Pilot Site.

Table 5 Overview over use of MOBiNET components in different releases

Components / Services

SD IdM Billing Mobi Agent

CM/CA TSP M DQA SDK Dashboard Privacy Framework

Parking

R2.0, R2.1, R3.0, R3.1, R4.0

R3.0, R3.1, R4.0

R3.1, R4.0

R2.0, R2.1, R3.0, R3.1, R4.0

R2.0, R2.1, R3.0, R3.1, R4.0

R2.0, R2.1, R3.0, R3.1, R4.0

RTTI*


02/06/2017 Page 30 of 55 Version 4.0

3. Methodology

3.1. Test responsibilities across the Sub Projects

Testing if often divided in verification and validation. To put it simple, one could put it like this:

Verification: Are we building the product right?

Validation: Are we building the right product?

In software development, the IEEE definition states (Verification and validation, 2013)

Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].

Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements [IEEE-STD-610].

In (D51.1 Mobinet) this has been interpreted in terms of the MOBiNET scope:

Verification determines if the MOBINET platform and services are consistent and perform the selected functions in the correct manner. Using a bottom-up approach verification ensures whether the requirements of the functional specifications at the higher levels are fulfilled. In general, verification addresses the requirements of what MOBiNET needs to consider for the design of its services and platform. For that, they need to be verified before deploying the services.

Validation analyses if the right platform and innovative services have been built, i.e. whether MOBINET’s platform and services comply with the objectives and perform the functions for which they were intended for, by assessing hypotheses and success criteria statements. Validation checks, using a top-down approach, the performance and effectiveness based on selected performance indicators. Validation addresses the effects of the innovative services: meaning how effectively the services respond to identified user (stakeholders) needs. As a consequence, the validation categories are always addressing the effects of the services in, for instance, social or environmental aspects.

It is not always clear where the boundary lies. In D5.1.1, this is visualised as shown hereunder.

Verification addresses requirements and specifications

o Component level

SP2 develops and tests the services such as GLOSA, MMTA and UBI

SP3 deliver the MOBiNET platform and performs the component tests and integration tests (test environment by Jenkins). It does a hand-over to SP4.

o System level

SP4 carrier out the system tests (on Virtual Machines) by using the SP3 test procedures and perform more operational tests. SP4 does a hand-over to SP5.


02/06/2017 Page 31 of 55 Version 4.0

SP5 carries out the verification plan on the runtime system on the Helmond testsite.

Validation addresses hypotheses derived from user (stakeholder) needs and use cases

o Takes place at the primary pilot sites, i.e. Helmond, Helsinki, Spain and North Denmark Region.

Figure 16 MOBiNET development time processes and relationships, taken from (D51.1)

According to the overall pilot planning (emdesk / SP5 / wp55 pilot coordination / MOBiNET pilot planning) the following time lines were planned:

Delivery of draft release 2 from SP2, SP3 and SP4 in March 2015.

Implementation and verification release 2, Marcg- April 2015

The validation process at all test sites May – July 2015.

3.2. Methodology of the North Denmark Pilot site

The previous section defines the scope and responsibility for the verification and validation.

Table 6 division of responsibility for verification and validation

Services Responsible partner


02/06/2017 Page 32 of 55 Version 4.0

Verification (bottom-up)

Testing the MOBiNET components as used by the service (deployment & usage)

Helmond

Validation (top-down)

Checking that the available components fulfill the needs of the service

Test sites (NDR)

Thus the primary focus will be on Validation, checking that the MOBiNET components fulfil the needs of the two services. While doing so any problems or malfunctions in the MOBiNET components will be reported to the relevant bodies (verification).

The validation will rely on several sources.

Feedback and systematically testing from service developers. Result from systematical tests using test specifications (test matrix) for all functions Result from surveys and questionnaires among test persons

To be able to do a validation on the MOBiNET components, the North Denmark Pilot has done a preceding verification and validation on the locally developed services.

Roles & Responsibilities:

Gatehouse has been responsible for the validation process and the test reporting.

The test matrix has been setup by Gatehouse.

Based on the test matrix WP5 have generated a questionnaire to be used during the validation.

Only for Helmond PS.


02/06/2017 Page 33 of 55 Version 4.0

4. Validation

4.1. Validation plans and guidelines

Validation has been done according to D5.1 and D52.1 (first IR 52.1) and D52.3

The North Denmark Pilot has validated the MOBiNET system using the two parking Services and the RTTI as test scenarios.

Besides a test user group of 30 testusers have been testing the parking functions from a user perspective.

Interoperability assessment has been done by the North Denmark test site and Trikala transferring the Parking service to Greece, and by Helmond and North Denmark transferring the RTTI service to Denmark. Before Release 4, validation followed fixed validation scenarios.

Validation of R 4. has been done by filling in a questionnaire structured by MOBiNET Components

Up til R.3.1 the following validation scenarios have been tested:

Create MOBiNET OpenID and manage identity Publish and manages B2B service Search and display B2B service Discover and use App REST API of Services Directory Authentication API Create Business Identity Create User Identity Publish B2B services Search for B2B services as a Services Provider Search for B2B services as an App Publish B2C App Search for App

The validation scenarios are shown in section 0 Validation Scenarios.

The R.4. validation questionnaire focused on the following subjects:

The Services Support Centre Management of User Identities in MOBiNET IdP Log in and use of MOBiNET Dashboard Communication Agent (Not relevant in North Denmark) Services Providers Development Kit Discover the Services Directory and Data Format Catalogue Widgets Explore the Analytics Widgets (Not relevant in North Denmark) Billing MOBiAgent Overall impression


02/06/2017 Page 34 of 55 Version 4.0

4.2. Results and recommendations after validation R4.0

Results of validation are reported via the online questionnaire developed by MOBiNET for this purpose.

The main conclusion, describing the quality and degree of maturity of the MOBiNET system after validation of Release 4.0 can be summarized in the following bullets:

Service Support center: o A good tool to find information on MOBiNET and understand the components of

MOBiNET o A search-feature is missing

Management of User ID using Dashboard: o The purpose of “My profile” is not clear o Unclear what role and permissions you get when logging in with Google account (what is

a singleUser?) o CRUD of user account works fine

Dashboard: o Good and quick overview of the relevant components

Communication agent: o Not tested

SDK: o The Eclipse IDE did not let us get to actually creating a Service Description, even though

we were following instructions (could not set a container which was needed in order to proceed).

Discovery in Service Directory and data format catalog o Easy to use and understand. Have no problems using it.

TSP o Not tested

Analytics widget o Not tested

Billing o In the documentation it is unclear what the various fields in the billing components are

used for and must contain (some are more obvious than others). o Tried purchasing NDR parking service clicking icon in Dashboard, but saw no billing

events as a result of that. MOBiAgent

o For the normal user, downloading through CrashLytics is not an option. Must be able to download and install using Google Play

o Searching for services may be less interesting for normal users, searching for apps only is. However, that is not possible.

o Good with search results linking directly into the Google Play store for apps.

In all, the MOBiNET platform has matured and for demonstration purposes, it is sufficient. However, there are some way still to go to have a commercial product.


02/06/2017 Page 35 of 55 Version 4.0

5. Conclusions and recommendations The North Denmark Pilot was involved in the realization of three services: B2B Parking Data Service, B2C Parking Service and the Real Time Traffic Information service.

The B2B Parking Data Service collects real-time parking information from a number of car parks and makes them available – through the MOBICENTER - for B2C services for example for offering guidance to nearest free car park in real-time. The services include a broader range of information for each car park, as number of free parking slots, number of parking slots for disabled and number of charging points for electrical vehicles. The information can be used for services as Find Nearest EV Charging Point etc.

The B2C Parking Service offers four different parking features to the end user, by using data form the B2B Parking Data service. The features are Route Guidance to nearest free parking bay, Automatic GPS based parking payment, Time-limited parking assistance and Find my parked car.

The RTTI offers Real time traffic information to car users in the users smartphone.

The Parking services were used for validation of the MOBiNET components, the Service Directory, the Identity Manager, the Billing, the MOBiAGENT, the Services Development Kit, and the Dashboard.

Implementing the parking service in Trikala by letting the parking service automatically use Greek parking data, registered by Trikala in the Service Directory, when parking in Trikala, and by letting Greek car drivers use Danish data and Danish payment system, when parking in Denmark, validates the transferability by using the MOBiNET platform.

Also moving the RTTI information service to Denmark by adding a Danish data stream, validates the transferability by using the MOBiNET platform.

Based on validating releases 2 to 4, the status after R4.0 is that all in all, the MOBiNET platform has matured and for demonstration purposes, it is sufficient. However, there is some way still to go to have a commercial product.


02/06/2017 Page 36 of 55 Version 4.0

Appendix I: Validation Test cases, scenarios and results

Validation Scenarios

As described earlier the validation process was changed before validating R4.0. from scenarios to a component based questionnaire.

This next section shows the validation scenarios used to test release 3.1.

Create MOBiNET OpenID and Manage identity

Validation Scenario ID

VS_AAL_CMID_SP_01-R2.1

Name Create MOBiNET OpenID and Manage identity

Requirement Category

Identity manager

Point of View (Stakeholder role)

Service provider

Description Create MOBiNET OpenID and manage identity (in simple user role) such as profile management, password change, etc.

Objective Evaluate if the identity model and functionality are sufficient for creating a MOBiNET OpenID and for managing own identity.

Validation Pilot site AAL

Requirements validated

Requirement ID

Release where

validatedRequirement

MP-54 1.0, 2.0,

2.1 Login to Dashboard

MP-57 2.1 Supported Browsers

MP-79 2.1 Create New MOBiNET account

MP-613 2.1 Management of User Identities in MOBiNET IdP

MP-714 2.1 Widget management Interface

Service(s) used in validation

The purpose of the validation scenario is generic (services are not required)

Process (validation 1) MP-714: Widget management Interface


02/06/2017 Page 37 of 55 Version 4.0

steps) Access widget management interface 2) MP-79: Create New MOBiNET account

This step includes also MP-54: Login to Dashboard Create new MOBiNET account (sign up) Login with new MOBiNET account (sign in)

3) MP-613: Management of User Identities in MOBiNET IdP This step includes also MP-54: Login to Dashboard

Login with MOBiNET account Manage user identity (this step includes management of

personal information & profile, password change, unregister and sign out)

4) MP-57: Supported Browsers The above are repeated for supported browsers

Notes

Publish and Manage B2B service


VS_AAL_PMS_SP_01-R2.1

Name Publish and Manage B2B Service


Service directory, SDK


Service Provider, Service Developer

Description

Publish a service in Service Directory and manage services in Service Directory.

Following cases are evaluated within this scenario:

Publish Aalborg Parking service by service provider.

Delete Aalborg Parking service by service provider.

Manage Aalborg Parking service by service provider; management may include edit service description, extending service description metadata as well as the coverage of the service.

Objective

Evaluate the service publishing tools provided by MOBiNET for the addition of B2B services.

This scenario evaluates the usability and intuitiveness of the service publishing tools as well as the coverage of the service and metadata options


02/06/2017 Page 38 of 55 Version 4.0

available for the service description.



Requirement ID

Release where validated

Requirement

MP-54 1.0, 2.0,

2.1 Login to Dashboard

MP-57 1.0, 2.0,

2.1 Supported browsers

MP-84 2.0, 2.1 Publish a Service to Service Directory

MP-85 2.0, 2.1 Associate Metadata With a Published Service

MP-86 2.1 Define Service Technical Details

MP-87 2.1 Define Cost for Service Usage (if applicable)

MP-89 2.0, 2.1 Define Service Coverage Area

MP-95 2.0, 2.1 Extend Service Metadata Description for a Service

MP-96 2.0, 2.1 Remove Service From Service Directory

MP-97 2.1 Activate/Deactivate service

MP-581 2.1 Service description should include owner and who registers this service

MP-584 2.1 Link service description to organization

MP-586 2.1 Associate USDL description with service description

MP-588 2.1 Extend widget functionalities

MP-595 2.1 Make widgets browser independent

MP-597 2.1 Language to be included in Service Description

MP-631 2.1 Extended Tutorials including a MOBiNET user manual of how to use components for service developers

MP-632 2.1 Improved Service Editor


02/06/2017 Page 39 of 55 Version 4.0

MP-671 2.1 Customize Dashboard Login Page for MOBiNET

MP-706 2.1 Provide inline and context sensitive help

MP-716 3.0 Add field "name" (searchable) to service description in addition to ID

MP-717 2.1 It should be possible to define a category based on pre-defined values

MP-718 3.0 Add licences agreement description to service description

MP-747 2.1 Editor: UI improvements: icons, tooltips

MP-748 2.1 Editor: Undo/redo operations

MP-749 2.1 Editor: adapt to the new (updated) service description format (work on-going)

MP-752 3.0 Editor: Online-Help

MP-753 3.0 Editor: Mandatory Fields

MP-793 3.0 Ensure that a developer only can manage/modify service descriptions from his own organization.


Aalborg Parking Service

Process (validation steps)

1) Create the Aalborg Parking Service using the Service Editor Include validation of the functionality related to the

requirements below: ‐ MP-85: Associate Metadata With a Published Service ‐ MP-95: Extend Service Metadata Description for a

Service ‐ MP-586:Associate USDL description with service

description ‐ MP-747: Editor: UI improvements: icons, tooltips ‐ MP-748: Editor: Undo/redo operations ‐ MP-749: Editor: adapt to the new (updated) service

description format (work on-going) ‐ MP-632: Improved Service Editor ‐ MP-717: It should be possible to define a category

based on pre-defined values ‐ MP-753: Editor: Mandatory Fields ‐ MP-588: Extended widget functionalities ‐ MP-595: Make widgets browser independent


02/06/2017 Page 40 of 55 Version 4.0

Include validation that the editor offers the functionality related to the requirements below:

‐ MP-86: Define Service Technical Details ‐ MP-87: Define Cost for Service Usage ‐ MP-89: Define Service Coverage Area ‐ MP-581: Service description should include owner and

who registers this service ‐ MP-584: Link service description to organization ‐ MP597: Language to be included in Service Description ‐ MP-716: Add field "name" (searchable) to service

description in addition to ID ‐ MP-718: Add licences agreement description to service

description

2) Publish the Aalborg Parking Service Include validation of the functionality related to the

requirements below: ‐ MP-84: Publish a Service to Service Directory ‐ MP-54: Login to Dashboard (both with MOBiNET and

Google OpenID) ‐ MP-57: Supported browsers ‐ MP-671: Customize Dashboard Login Page for

MOBiNET ‐ MP-706: Provide inline and context sensitive help

3) Activate/Deactivate Service Include validation of the functionality related to the

requirements below: ‐ MP-97: Activate/Deactivate service ‐ MP-54: Login to Dashboard (both with MOBiNET and

Google OpenID) ‐ MP-793: Ensure that a developer only can

manage/modify service descriptions from his own organization.

4) Remove Service from Service Directory Include validation of the functionality related to the

requirements below: ‐ MP-96: Remove Service From Service Directory ‐ MP-54: Login to Dashboard (both with MOBiNET and

Google OpenID) 5) Support and Documentation

MP-631: Extended Tutorials including a MOBiNET user manual of how to use components for service developers

MP-706: Provide inline and context sensitive help MP-752: Editor: Online-Help

Notes For the validation process the Service Description Editor (standalone application) must be provided.


02/06/2017 Page 41 of 55 Version 4.0

Search and Display B2B service


VS_AAL_SDS_SP_01-R2.1

Name Search and Display B2B Service


Service directory, SDK


Service Provider, Service Developer

Description Search a service in Service Directory and present service description.

Objective This scenario evaluates the power and usability of the service discovery functionality offered by dashboard by including searching of the just published service in various ways.



Requirement ID


Requirement

ID R Name

MP-54 1.0, 2.0, 2.1 Login to Dashboard

MP-57 1.0, 2.0, 2.1 Supported browsers

MP-83 1.0, 2.0, 2.1 Search Service Directory

MP-86 2.0, 2.1 Define Service Technical Details

MP-87 2.1 Define Cost for Service Usage

MP-89 2.0, 2.1 Define Service Coverage Area

MP-97 2.0, 2.1 Activate/Deactivate service

MP-581 2.1 Service description should include owner and who registers this service

MP-582 2.1 Search function

MP-584 2.1 Link service description to organization

MP-590 2.1 Search for services based on output data type/format

MP-595 2.0, 2.1 Make widgets browser independent


02/06/2017 Page 42 of 55 Version 4.0

MP-597 2.1 Language to be included in Service Description

MP-671 2.1 Customize Dashboard Login Page for MOBiNET

MP-716 2.1 Add field "name" (searchable) to service description in addition to ID

MP-718 3.0 Add licences agreement description to service description

MP-720 2.1 Possibility to list all existing apps/services

MP-721 2.1 Improvements searching for services (state of the art)

MP-734 2.1 Possibility to list all existing services

MP-722 2.1 Display geographical area on map when showing details of Service Description


Aalborg Parking Service (and other services published in the MOBiNET Service Directory)


1) Search Service Directory a. Search for the Aalborg Parking service published during the

previous validation scenario (VS_AAL_PMS_SP_01-R2.1) using both the simple and advanced search options.

b. Search with all possible ways to test richness of the search functionality

c. Search published service both after activation of the service and after de-activation of the service

Include validation of the functionality related to the requirements below:

‐ MP-83: Search Service Directory ‐ MP-54: Login to Dashboard (both with MOBiNET and

Google OpenID) ‐ MP-57: Supported browsers ‐ MP-671: Customize Dashboard Login Page for

MOBiNET ‐ MP-582: Search function ‐ MP-590: Search for services based on output data

type/format ‐ MP-97: Activate/Deactivate service ‐ MP-595: Make widgets browser independent ‐ MP-720: list all services ‐ MP-721: Improvements searching for services (state of

the art)


02/06/2017 Page 43 of 55 Version 4.0

‐ MP-734: Possibility to list all existing services 2) View Service Description

This step ensures that the detailed description of a service published in MOBiNET platform can be viewed.

Include validation that the service description incorporates the information related to the requirements below:

‐ MP-86: Define Service Technical Details ‐ MP-87: Define Cost for Service Usage ‐ MP-89: Define Service Coverage Area ‐ MP-581: Service description should include owner and

who registers this service ‐ MP-584: Link service description to organization ‐ MP597: Language to be included in Service Description ‐ MP-716: Add field "name" (searchable) to service

description in addition to ID ‐ MP-718: Add licences agreement description to service

description ‐ MP-722: Display geographical area on map when

showing details of Service Description

Notes

Discovery and Use of App


VS_AAL_DUA_EU_01-R2.1

Name Discovery and Use of App


App discovery and use


End user

Description

This scenario evaluates the realization of end user interface to MOBiNET as well as deployment and use of MOBiNET applications (such as the Aalborg Parking Service app) in the MOBiAGENT context.

Objective

The evaluation concentrates on the following end user topics:

installation and configuring MOBiAGENT environment in the user terminal,

creation of personalised MOBiNET end user account,

app discovery

app deployment


02/06/2017 Page 44 of 55 Version 4.0

app management and usage in MOBiAGENT environment

The topics above are tested in different terminal environments in order to test functioning and usability in various sizes of screens and operating system versions. In addition, app discovery using web interface is evaluated in different browser environments.

Validation Pilot site TRI


Requirement ID


Requirement

ID R Name

MP-29 1.0, 2.0,

2.1 Mobile Device Screen Size

MP-41 1.0, 2.0,

2.1 App Store UI

MP-43 1.0, 2.0,

2.1 Search App Store

MP-79 2.1 Create New MOBiNET account

MP-420 2.0, 2.1 Install MOBiAGENT from App Store

MP-783 3.0 Make MOBiAGENT compatible with Android version 5.x

MP-596 2.1 For all type of end user services

MP-605 2.0, 2.1 Update AppDirectory UI

MP-610 2.0, 2.1 Install MOBiAGENT extensions

MP-620 2.0, 2.1 Add Google as external IDP to MOBiNET

MP-647 2.0, 2.1 Service Discovery Widget

MP-652 2.0, 2.1 MOBiAGENT end-user UI integration

MP-790 3.0 Integrate Webviews into UI of MOBiAGENT (e.g. AppDirectory UI)

MP-791 3.0 Change start screen of MOBiAGENT to MOBiNET Login-Page


Aalborg Parking Service.

Process (validation 1) Installation of MOBiAGENT on android device

Download and install MOBiAGENT and required extensions via


02/06/2017 Page 45 of 55 Version 4.0

steps) Google Play Beta program: https://play.google.com/apps/testing/org.mobinet.mobiagent


‐ MP-420: Install MOBiAGENT from app store ‐ MP-26: Android Operating System ‐ MP-783: Make MOBiAGENT compatible with Android

version 5.x ‐ MP-610: Install MOBiAGENT extensions (if required)

2) Log into MOBiNET as end user Include validation of the functionality related to the

requirements below: ‐ MP-79: Create New MOBiNET Account (if necessary) ‐ MP-620: Add Google as external IDP to MOBiNET (as

background information) ‐ MP-791: Change start screen of MOBiAGENT to

MOBiNET Login-Page 3) Experiment end user interface offered by MOBiAGENT using different

end user terminal environments Include validation of the functionality related to the

requirements below: ‐ MP-41: App Store UI (general view) ‐ MP-790: Integrate Webviews into UI of MOBiAGENT

(e.g. AppDirectory UI) ‐ MP-26: Android Operating System ‐ MP-29: Mobile Screen Size ‐ MP-652: MOBiAGENT end-user UI integration

4) Search Apps Store and App Retrieval By using MOBiAGENT end user UI, search applications in

various ways in order to find out what apps are available. Specifically search Parking app. Check how different kinds of end user apps and services are found and how their service descriptions are presented.

Once the desired end user app is found test how it can be retrieved.


‐ MP-43: Search Apps Store ‐ MP-596: For all type of end user services ‐ MP-605: Update AppDirectory UI ‐ MP-647: Service Discovery Widget ‐ MP-41: App Store UI

5) Evaluate MOBiNET environment from end-user perspective Does MOBiAGENT bring added value for end user application

discovery, deployment and use? Evaluate acceptance (usefulness, friendliness, etc.)


02/06/2017 Page 46 of 55 Version 4.0

Uninstall the MOBiNET application (and see implications)

Notes

The prerequisite is that the Parking app (or any other relevant app) is available for Aalborg.

REST API of Service Directory


VS_AAL_REST_EU_01-R2.1

Name REST API of Service Directory


Service discovery and management


Service Provider

Description Creation, modification, deletion, searching for apps and services in the service directory based on the available REST API to the Service Directory.

Objective This scenario verifies the usability MOBiNET Service Directory REST API.



Requirement ID


Requirement

ID R Name

MP-591 2.0 REST API of Service Directory




1) MP-54: REST API of Service Directory: Add service Modify service Search published service Delete service Add app Modify app Search published app Delete app


02/06/2017 Page 47 of 55 Version 4.0

Authentication API


VS_AAL_ AAPI_EU_01-R2.1

Name Authentication API


??


Service Provider

Description On behalf of an end user, use the authentication API to validate an end users MOBiNET identity.

Objective Verify the authentication API of MOBiNET.



Requirement ID


Requirement

ID R Name

MP-699 2.1 Authentication API




1) Using a MOBiNET end users credentials, use the API for validating the users MOBiNET identity.

2) Using invalid user credentials use the API for validating that the user does not have a MOBiNET identity.

Create Business Identity


VS_AAL_ ??

Name Create Business Identity


??


Service Provider

Description As a business, create an identity for accessing the MOBiNET dashboard,


02/06/2017 Page 48 of 55 Version 4.0

based on the available description of the service. After creation, modify and delete the identity.

Objective Evaluate the identity management service with regards to creating, modifying, and deleting a business identity using the tools provided by MOBiNET.



Requirement Applicable (Yes / Why not)

ID Name

MP-??

Create MOBiNET business identity??

Yes

MP-??

Modify MOBiNET business identity

Yes

MP-??

Delete MOBiNET business identity

Yes

MP-54

Login to Dashboard Yes.

MP-??

Logout of Dashboard Yes




1) Create MOBiNET business identity?? 2) MP-54: Log into Dashboard 3) Modify MOBiNET business identity?? 4) Log out of Dashboard 5) Login to Dashboard and verify that modifications persist 6) Delete MOBiNET business identity?? 7) Login to Dashboard; verify that login is rejected

Create User Identity

Creating user identities is not available in R1.


VS_AAL_ ??

Name Create Business Identity


??

Point of View Customer


02/06/2017 Page 49 of 55 Version 4.0

(Stakeholder role)

Description As a customer, create an identity for accessing the MOBiNET app directory etc., based on the available description of the service. After creation, modify and delete the identity.

Objective Evaluate the identity management service with regards to creating, modifying, and deleting a customer identity using the tools provided by MOBiNET.




ID Name

MP-??

Create MOBiNET customer identity??

Yes

MP-??

Modify MOBiNET customer identity??

Yes

MP-??

Delete MOBiNET customer identity??

Yes

MP-??

Log into MOBiNET app directory??

Yes

MP-??

Log out of MOBiNET app directory

Yes




1) Create MOBiNET customer identity?? 2) Log into MOBiNET app directory?? 3) Modify MOBiNET customer identity?? 4) Logout of MOBiNET app directory 5) Log into MOBiNET app directory; verify that changes persist 6) Delete MOBiNET customer identity?? 7) Log into MOBiNET app directory; verify that login is rejected

Publish B2B Service


VS_AAL_ ??

Name Publish B2B Service

Requirement Service discovery and management


02/06/2017 Page 50 of 55 Version 4.0

Category


Service Provider

Description Publish an open data source and service in the service directory based on the available description of the service and its APIs. After publishing of the service searching the added service is tested in various ways.

Objective

Evaluate the service publishing tools provided by MOBiNET in the addition of the existing B2B service. The special emphasis is on the construction of the MOBiNET service description based on the publicly available service description with complete API definition. This scenario evaluates the usability and intuitiveness of the service publishing tools as well as the coverage of the service description and metadata options available for the service description.

In addition, this scenario evaluates the power and usability of the service discovery by including searching of the just published service in various ways.




ID Name

MP-51 Service Usage Statistics

No. No usage for the published service at this stage.

MP-52 History of usage No. No usage for the published service at this stage.

MP-54 Login to Dashboard Yes.

MP-83 Search Service Directory

Validated.

MP-84 Publish a Service to Service Directory

Yes.

MP-85 Associate Metadata With a Published Service

Yes.

MP-89 Define Service Coverage Area

Yes.

MP-95 Extend Service Metadata Description for a Service

Yes.


02/06/2017 Page 51 of 55 Version 4.0

MP-96 Remove Service From Service Directory

Yes.

MP-97 Activate/Deactivate service

Yes.




8) MP-54: Login to Dashboard 9) MP-84: Publish a Service to Service Directory

Publish the service with minimum service description to test deletion of the service

10) MP-96: Remove Service From Service Directory 11) MP-84: Publish a Service to Service Directory

Re-publish the service with full description 12) MP-85: Associate Metadata With a Published Service 13) MP-89: Define Service Coverage Area 14) MP-95: Extend Service Metadata Description for a Service 15) MP-97: Activate/Deactivate service 16) MP-83: Search Service Directory

Search published service both after activation of the service and after de-activation of the service

Search for B2B Service as a Service Provider


VS_AAL_ ??

Name Search for B2B Service as a service provider




Service Provider

Description Searching for an added service is tested in various ways

Objective

This scenario evaluates the usability and intuitiveness of the service search tools as well as the coverage of the service description and metadata options available for the service description.

In addition, this scenario evaluates the power and usability of the service discovery by including searching of the published service in various ways.




02/06/2017 Page 52 of 55 Version 4.0


ID Name


Yes

MP-54 Login to Dashboard Yes.




2) MP-54: Login to Dashboard 3) MP-83: Search Service Directory

Search published service after activation of the service. Search on various criteria:

i. Geographical area ii. Service type

Search for B2B Service as an App


VS_AAL_ ??

Name Search for B2B Service as an app




Service Provider

Description Searching for an added service is tested in various ways, as well as connecting to the found service is tested.

Objective

This scenario evaluates the usability of the service search tools available for apps, as well as the coverage of the service description and metadata options available for the service description.

In addition, this scenario evaluates the power and usability of the service discovery by including searching of the published service in various ways.

A final objective is to evaluate if connecting to the service, based on the metadata of the service published in the service directory, is possible.




ID Name


02/06/2017 Page 53 of 55 Version 4.0

MP-98 Connect to a Service in Service Directory

Yes


Yes

MP-?? Login to Service Directory as an App

Yes.




4) MP-54: Login to Service Directory as an App 5) MP-83: Search Service Directory

Search published services. Search on various criteria:

i. Geographical area ii. Service type

6) MP-98: Connect to a Service in the Service Directory;use the data in the directory to connect to the service.

Publish B2C App


VS_AAL_ ??

Name Publish B2C Application


App discovery and management


Service Provider

Description Publish an app in the App Directory provided by MOBiNET

Objective

Evaluate the app publishing tools provided by MOBiNET in the addition of the existing B2C service. The special emphasis is on the construction of the MOBiNET service description based on the publicly available service description. This scenario evaluates the usability and intuitiveness of the app publishing tools as well as the coverage of the app description and metadata options available for the app description.





02/06/2017 Page 54 of 55 Version 4.0

ID Name

MP-??

App Usage Statistics No. No usage for the published app at this stage.

MP-??

History of usage No. No usage for the published app at this stage.

MP-54


MP-??

Search App Directory Yes.

MP-??

Publish an App to App Directory

Yes.

MP-??

Associate Metadata With a Published App

Yes.

MP-??

Extend Service Metadata Description for an App

Yes.

MP-??

Remove App From Service Directory

Yes.

MP-??

Activate/Deactivate App

Yes.




1) MP-54: Login to Dashboard 2) MP-??: Search App Directory for various criteria:

a. Search Apps b. Search on various criteria:

i. Geographical area ii. App type

3) MP-??: Publish an App to App Directory 4) MP-??: Associate Metadata With a Published App 5) MP-??: Extend Service Metadata Description for an App 6) MP-?? Activate/Deactivate App 7) MP-?? Remove App From Service Directory


02/06/2017 Page 55 of 55 Version 4.0

Search for App


VS_AAL_ ??

Name Search B2C Application


App discovery and management


Customer

Description Search for an app in the app directory based on the available description of the app and its APIs. After finding the app the customer shall be brought to a state where installing the app is eminent.

Objective

Evaluate the app search tools provided by MOBiNET in context of the existing B2C service. Special emphasis is on finding an appropriate app based on the MOBiNET app description. This scenario evaluates the usability and intuitiveness of the app search tools as well as the coverage of the app description and metadata options available for the app description.




ID Name

MP-51

Service Usage Statistics

No. No usage for the published service at this stage.

MP-52

History of usage No. No usage for the published service at this stage.

MP-54


MP-??

Search App Directory Validated.




1) MP-54: Login to Dashboard 2) MP-??: Search App Directory

Search published app Sort search results based on usage statistics Get directed to where the app can be found.

Documents

MOBiNET DEL D5.14 PilotNorthDenmark v4.0 20170602 · from drawing for simplification). ... in UML as an “actor”) and a system, ... D51.2 5.2 Validation and assessment plan