DELIVERABLE - optimumproject...JSI (Luka Bradesko, Zala Herga), NISSA (Nenad Stojanovic, Jovica Zlatanovic), FLU (Stephan Strodl), KAPSCH (Gabriel Makki, Rodrigo Barco) Integration

Project Acronym: OPTIMUM

Grant Agreement number: 636160 (H2020-MG-7.1 - RIA)

Project Full Title: Multi-source Big Data Fusion Driven Proactivity for Intelligent

Mobility

DELIVERABLE

D6.3 – Integrated OPTIMUM Platform

Dissemination level Public

Type of Document Report

Contractual date of delivery 31/12/2016

Actual Date of Delivery 28/12/2016

Deliverable Number D6.3

Deliverable Name Integrated OPTIMUM Platform – Initial version

Deliverable Leader INTRASOFT

Work package(s) WP6

Status & version Final, v.1.0

Number of pages 89

WP contributing to the deliverable WP1, WP2, WP3, WP4, WP5

WP / Task responsible WP6 / All tasks

Coordinator (name / contact) Mr. Konstantinos Thiveos (INTRASOFT International)

Other Contributors UoW, ICCS, JSI, NISSA, AIT, FLU, UNINOVA, KAPSCH

EC Project Officer Mr. Walter Mauritsch (EC, INEA)

Keywords: Proactivity, data fusion, big data processing, transport

forecasting, dynamic charging, multimodal routing,

persuasive technologies, information personalization.

Abstract (few lines): The scope of the current document is to accompany

the Integrated OPTIMUM Platform prototype, and

document the integration efforts that took place for

the delivery of the holistic platform. The integration

efforts comprise mainly of the development of the

technical interfaces which enable the information

Project Title: OPTIMUM

Contract No. 636160 Project Coordinator: INTRASOFT International S.A.

Page | 2

D6.3 – Integrated OPTIMUM Platform – Initial version,

v.1.0, 28/12/2016

exchange between the components of the platform.

In order to facilitate better understanding regarding

the inter-communication of the various components,

we highlight the functionalities of the OPTIMUM

platform, broken down into functionalities provided

to the two target end user categories of the platform,

namely users of the OPTIMUM mobile application,

and users of the OPTIMUM web application. Apart

from the documentation of the functionalities

supported and the information exchange amongst

the platform’s components, the current deliverable

undertakes the documentation of the installation

instructions required in order to set up the OPTIMUM

platform and operate it outside the context of the

project. Last but not least, the deliverable documents

the Software Quality Assurance Plan, the aim of

which is to provide a single point of reference on the

SW quality that will be governed during the course of

the project. Within the context of this deliverable we

define the SW quality control and quality assurance

activities that need to be carried out, in order to

ensure that standards, processes, and procedures are

defined and their execution is continuously

monitored and improved.



Page | 3


v.1.0, 28/12/2016

Document History Document History

Version Date Contributor(s) Description

v.0.1 05/12/2016 INTRASOFT (Konstantinos Perakis) Table of Contents

v.0.2 06/12/2016 INTRASOFT (Konstantinos Perakis)

Minor revisions on

allocations and circulation

to partners

v.0.3 07/12/2016 KAPSCH (Rene List) Software Quality Assurance

(Chapter 4)

v.0.4 09/12/2016 INTRASOFT (Konstantinos Perakis,

Spyros Mantzouratos)

Mobile Application

functionalities descriptions

and sequence diagrams


Web Interface

functionalities descriptions

and sequence diagrams

v.0.6 15/12/2016

JSI (Luka Bradesko, Zala Herga), NISSA

(Nenad Stojanovic, Jovica Zlatanovic),

FLU (Stephan Strodl), KAPSCH (Gabriel

Makki, Rodrigo Barco)

Integration of inputs in

chapters 2 and 3.

v.0.7 16/12/2016

ICCS (Thimios Bothos, Babis

Maggoutas, Evangelia

Anagnostopoulou), UoW (Ioannis

Petalas, Panagiotis Georgakis), AIT

(Clovis Seragiotto, Matthias

Prandstetter, UNINOVA (Paulo

Figueras)

Integration of inputs in

chapters 2 and 3.


Internal review ready

version (introduction,

conclusions & annexes)

v.0.9 21/12/2016

NISSA (Nenad Stojanovic), UoW

(Panagiotis Georgakis), KAPSCH

(Gabriel Makki)

Prefinal version

consolidating internal

reviewers’ comments

v.0.99 23/12/2016 INTRASOFT (Konstantinos Perakis) Final version

v.1.0 28/12/2016 INTRASOFT (Akrivi Kiousi, Irene

Matzakou)

QA, Final Approval,

Submission to the EC



Page | 4


v.1.0, 28/12/2016

1 Table of Contents Document History ........................................................................................................................... 3

Executive Summary ......................................................................................................................... 9

1 Introduction ........................................................................................................................... 10

1.1 Structure ....................................................................................................................... 10

2 OPTIMUM Integrated Platform ............................................................................................. 12

2.1 OPTIMUM Mobile Application Functionalities ............................................................. 12

2.1.1 Registration ............................................................................................................... 13

2.1.2 Mobility Preferences Selection ................................................................................. 15

2.1.3 Trip Planning ............................................................................................................. 18

2.1.4 (System-Triggered) Trip Management ...................................................................... 27

2.1.5 Motorhome Route Planning ..................................................................................... 48

2.1.6 Trip Evaluation .......................................................................................................... 59

2.2 OPTIMUM Web Interface Functionalities ..................................................................... 61

2.2.1 Dynamic Charging ..................................................................................................... 61

3 OPTIMUM Platform Installation ............................................................................................ 67

3.1 OPTIMUM Platform Installation ................................................................................... 67

4 OPTIMUM Software Quality Assurance ................................................................................ 77

4.1 SW Development Method ............................................................................................ 78

4.2 Software Implementation - Process flow ..................................................................... 80

4.3 SW Quality Artefacts ..................................................................................................... 83

4.3.1 Design ........................................................................................................................ 83

4.3.2 SW Code .................................................................................................................... 83

4.3.3 Code Analysis ............................................................................................................ 84

4.3.4 Unit Tests (module test) ........................................................................................... 85

4.3.5 Developer Tests ........................................................................................................ 85

4.3.6 Packaged Deployed SW ............................................................................................ 85

4.4 Software Quality ToolSet (recommended) ................................................................... 85

4.5 SW Quality Monitoring and Controlling ....................................................................... 87



Page | 5


v.1.0, 28/12/2016

4.5.1 Method and Tool ...................................................................................................... 87

4.5.2 Defined KPI´s/Metrics ............................................................................................... 87

4.5.3 Source Code .............................................................................................................. 87

4.5.4 Unit Tests .................................................................................................................. 87

4.5.5 Bug Tracking .............................................................................................................. 87

5 Conclusions ............................................................................................................................ 88

6 References ............................................................................................................................. 89

2 Table of Figures FIGURE 1: OPTIMUM MOBILE APP USER REGISTRATION ....................................................................................................... 13 FIGURE 2: OPTIMUM MOBILITY PREFERENCES SELECTION ..................................................................................................... 15 FIGURE 3: OPTIMUM TRIP PLANNING ................................................................................................................................ 18 FIGURE 4: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT ........................................................................................... 28 FIGURE 5: OPTIMUM MOTORHOME ROUTE PLANNING ......................................................................................................... 49 FIGURE 6: OPTIMUM TRIP EVALUATION ............................................................................................................................. 59 FIGURE 7: OPTIMUM DYNAMIC CHARGING......................................................................................................................... 62 FIGURE 8: SCRUM WORKFLOW ........................................................................................................................................... 78 FIGURE 9: KANBAN BOARD ................................................................................................................................................. 79 FIGURE 10: SOFTWARE IMPLEMENTATION PROCESS ................................................................................................................ 82

3 List of Tables TABLE 1: OPTIMUM MOBILE-APP USER REGISTRATION –MOBILE-APP/MOBILITY-HUB INTERFACE .................................................. 14 TABLE 2: OPTIMUM MOBILITY PREFERENCES SELECTION –MOBILE-APP/MOBILITY-HUB INTERFACE ................................................ 16 TABLE 3: OPTIMUM TRIP PLANNING –MOBILE-APP/MOBILITY-HUB INTERFACE .......................................................................... 19 TABLE 4: OPTIMUM TRIP PLANNING – MOBILITY-HUB/MULTIMODAL-ROUTER INTERFACE ............................................................ 20 TABLE 5: OPTIMUM TRIP PLANNING –MULTIMODAL-ROUTER/TRAFFIC-FORECASTER INTERFACE .................................................... 21 TABLE 6: OPTIMUM TRIP PLANNING –MULTIMODAL-ROUTER/MOBILITY-HUB INTERFACE ............................................................ 23 TABLE 7: OPTIMUM TRIP PLANNING –MOBILITY-HUB/RECOMMENDER INTERFACE ..................................................................... 24 TABLE 8: OPTIMUM TRIP PLANNING – MOBILITY-HUB/MOBILE-APP INTERFACE ......................................................................... 25 TABLE 9: OPTIMUM TRIP PLANNING –MOBILE-APP/MOBILITY-HUB INTERFACE .......................................................................... 26 TABLE 10: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – MOBILITY-HUB/PUB-SUB-MECHANISM INTERFACE ...................... 29 TABLE 11: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – RAW-DATA-ADAPTERS/PUB-SUB-MECHANISM INTERFACE............ 30 TABLE 12: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – TRAFFIC-FORECASTER/PUB-SUB-MECHANISM INTERFACE ............. 32 TABLE 13: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – PUB-SUB-MECHANISM/CEP INTERFACE .................................... 34 TABLE 14: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – CEP/PUB-SUB-MECHANISM INTERFACE .................................... 34



Page | 6


v.1.0, 28/12/2016

TABLE 15: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – PUB-SUB-MECHANISM/ RECOMMENDER INTERFACE ................... 35 TABLE 16: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – RECOMMENDER/MOBILITY-HUB INTERFACE .............................. 36 TABLE 17: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – MOBILITY-HUB/MOBILE-APP INTERFACE ................................... 38 TABLE 18: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT –MOBILE-APP/MOBILITY-HUB INTERFACE.................................... 40 TABLE 19: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – MOBILITY-HUB/MULTIMODAL-ROUTER INTERFACE ..................... 41 TABLE 20: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT –MULTIMODAL-ROUTER/TRAFFIC-FORECASTER INTERFACE ............. 42 TABLE 21: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT –MULTIMODAL-ROUTER/MOBILITY-HUB INTERFACE ...................... 43 TABLE 22: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT –MOBILITY-HUB/RECOMMENDER INTERFACE ............................... 44 TABLE 23: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT – MOBILITY-HUB/MOBILE-APP INTERFACE ................................... 46 TABLE 24: OPTIMUM (SYSTEM-TRIGGERED) TRIP MANAGEMENT –MOBILE-APP/MOBILITY-HUB INTERFACE.................................... 47 TABLE 25: OPTIMUM MOTORHOME ROUTE PLANNING –MOBILE-APP/MOBILITY-HUB INTERFACE ................................................. 50 TABLE 26: OPTIMUM MOTORHOME ROUTE PLANNING – MOBILITY-HUB/MULTIMODAL-ROUTER INTERFACE................................... 51 TABLE 27: OPTIMUM MOTORHOME ROUTE PLANNING –MULTIMODAL-ROUTER/TRAFFIC-FORECASTER INTERFACE .......................... 52 TABLE 28: OPTIMUM MOTORHOME ROUTE PLANNING –MULTIMODAL-ROUTER/MOBILITY-HUB INTERFACE ................................... 54 TABLE 29: OPTIMUM MOTORHOME ROUTE PLANNING –MOBILITY-HUB/RECOMMENDER INTERFACE ............................................ 55 TABLE 30: OPTIMUM MOTORHOME ROUTE PLANNING – MOBILITY-HUB/MOBILE-APP INTERFACE ................................................ 57 TABLE 31: OPTIMUM MOTORHOME ROUTE PLANNING –MOBILE-APP/MOBILITY-HUB INTERFACE ................................................. 58 TABLE 32: OPTIMUM TRIP EVALUATION –MOBILE-APP/MOBILITY-HUB INTERFACE ..................................................................... 59 TABLE 33: OPTIMUM DYNAMIC CHARGING –WEB-APP/DYNAMIC-CHARGER INTERFACE .............................................................. 62 TABLE 34: OPTIMUM DYNAMIC CHARGING –DYNAMIC-CHARGER/DYNAMIC-CHARGING-API INTERFACE ........................................ 63 TABLE 35: OPTIMUM DYNAMIC CHARGING – DYNAMIC-CHARGER/WEB-APP INTERFACE ............................................................. 65 TABLE 36: OPTIMUM DATA HARMONISATION ..................................................................................................................... 67 TABLE 37: OPTIMUM SECURITY SERVICE ............................................................................................................................. 67 TABLE 38: OPTIMUM PUB-SUB-MECHANISM....................................................................................................................... 69 TABLE 39: OPTIMUM CEP................................................................................................................................................ 70 TABLE 40: OPTIMUM TRAFFIC FORECASTING SERVICE ............................................................................................................ 70 TABLE 41: OPTIMUM SOCIAL MINING SERVICE ..................................................................................................................... 71 TABLE 42: OPTIMUM MULTIMODAL ROUTING SERVICE .......................................................................................................... 72 TABLE 43: OPTIMUM RECOMMENDATION SERVICE ............................................................................................................... 72 TABLE 44: OPTIMUM MOBILITY-HUB ................................................................................................................................. 72 TABLE 45: OPTIMUM TRACKING SERVICE ............................................................................................................................ 73 TABLE 46: OPTIMUM DYNAMIC CHARGING SERVICE .............................................................................................................. 73 TABLE 47: OPTIMUM WEB APPLICATION ............................................................................................................................ 75 TABLE 48: OPTIMUM WATCHDOG .................................................................................................................................... 76 TABLE 49: OPTIMUM API MANAGEMENT CONSOLE ............................................................................................................. 76 TABLE 50: S.O.L.I.D PRINCIPLES ......................................................................................................................................... 84



Page | 7


v.1.0, 28/12/2016

4 Definitions, Acronyms and Abbreviations

Acronym Title

API Application Programming Interface

CEP Complex Event Processor / Processing

CO Confidential, only for members of the consortium (including Commission Services)

CO2 Carbon Dioxide

CR Change Request

CSV Comma Separated Values

DATEX Data Exchange

DFD Data Flow Diagram

DL Deliverable Leader

Dx Deliverable (where x defines the deliverable identification number e.g. D1.1.1)

EDA Event Driven Architecture

EIM Exploitation Innovation Manager

EU European Union

GPS Global Positioning System

HTTP HyperText Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

I/O Input / Output

ID Identification

IP Internet Protocol

JSON JavaScript Object Notation

JWE JSON Web Encryption

JWT JSON Web Token

Mx Month (where x defines a project month e.g. M10)

OAuth Open Authorization

PC Project Coordinator

PM partner Project Manager

PO Project Officer

POI Point of Interest

PP Restricted to other programme participants (including the Commission Services)

PU Public

PubSub Publish-Subscribe Middleware

QA Quality Assurance



Page | 8


v.1.0, 28/12/2016

QAP Quality Assurance Plan

QFD Quality Function Deployment

QM Quality Manager

R Report

RE Restricted to a group specified by the consortium (including Commission Services)

REST Representational State Transfer

RUP Rational Unified Process

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SPARQL Simple Protocol and Resource Description Framework Query Language

STEP Standard Technology Evaluation Process

STM Scientific and Technical Manager

TL Task Leader

WP Work Package

WPL Work Package Leader



Page | 9


v.1.0, 28/12/2016

Executive Summary The scope of the current document is to accompany the Integrated OPTIMUM Platform

prototype, and document the integration efforts that took place for the delivery of the holistic

platform. The integration efforts comprise mainly of the development of the technical

interfaces which enable the information exchange between the components of the platform. In

order to facilitate better understanding regarding the inter-communication of the various

components, we highlight the functionalities of the OPTIMUM platform, broken down into

functionalities provided to the two target end user categories of the platform, namely users of

the OPTIMUM mobile application, and users of the OPTIMUM web application. These main

functionalities for the user of the OPTIMUM mobile application include: 1) The registration of

the mobile application user, 2) the selection of the mobility preferences, 3) the planning of a

trip, 4) the management / modification of a trip, triggered by the system, 5) the planning of a

route for motorhome users and 6) the evaluation of the application. From the perspective of

the users of the OPTIMUM web interface, the main functionality offered regards the request

for discounted toll prices for a specific route, with a side functionality offered being the

retrieval of the requests that have already been made. For each functionality, we provide

sequence diagrams, highlighting the individual components which have been integrated in

order to support the functionality. In turn, we document the technical interfaces between the

various components interacting in order to support the functionality, providing the technical

details that guided the integration efforts.

Apart from the documentation of the functionalities supported and the information exchange

amongst the platform’s components, the current deliverable undertakes the documentation of

the installation instructions required in order to set up the OPTIMUM platform and operate it

outside the context of the project.

Last but not least, the deliverable documents the Software Quality Assurance Plan, the aim of

which is to provide a single point of reference on the SW quality that will be governed during

the course of the project. Within the context of this deliverable we define the SW quality

control and quality assurance activities that need to be carried out, in order to ensure that

standards, processes, and procedures are defined, and their execution is continuously

monitored and improved. The consortium has opted for the adoption of the Scrumban method,

and has also defined artefacts to guarantee the software quality for the delivered software,

including: Design, SW Code, Code analysis, Unit Tests, Developer tests and Packaged, deployed

SW, and has also defined the recommended Software Quality ToolSet to guarantee and upraise

the quality of the produced results.



Page | 10


v.1.0, 28/12/2016

1 Introduction The scope of the current document is to accompany the Integrated OPTIMUM Platform


platform. The integration efforts comprise mainly of the development of the technical

interfaces recognized and documented in the context of D6.1, which enable the information

exchange between the components comprising the platform. In order to facilitate better

understanding regarding the inter-communication of the various components, we highlight the

functionalities of the OPTIMUM platform, broken down into functionalities provided to the two

target end user categories of the platform, namely users of the OPTIMUM mobile application,

and users of the OPTIMUM web application. We provide the sequence diagram of the

functionality to be supported as per the corresponding use case that has been documented in

D1.3, highlighting the individual components as these have been documented in the technical

architecture in D6.1, which have been integrated in order to support the functionality. In turn,

we document the technical interfaces between the various components interacting in order to

support the functionality, providing the technical details that guided the integration efforts.

Modifications and enhancements in the technical architecture based upon the outcomes of the

pilot trials, will be documented in the context of deliverable D6.5 in M31.

Apart from the documentation of the functionalities supported and the information exchange

amongst the platform’s components, the current deliverable undertakes the documentation of

the installation instructions required in order to set up the OPTIMUM platform and operate it

outside the context of the project. Within the context of the current deliverable, we document

the pre-requisites for deploying each component, along with the deployment scripts and

commands for its execution.

Last but not least, the deliverable documents the Software Quality Assurance Plan, the aim of

which is to provide a single point of reference on the SW quality that will be governed during

the course of the project. Within the context of this deliverable we define the SW quality


standards, processes, and procedures are defined and their execution is continuously

monitored and improved.

1.1 Structure The deliverable has been divided into the following chapters:

Chapter 1 introduces the deliverable, describes its scope, its relation to other

deliverables and its structure.

Chapter 2 documents the integration efforts that took place for the delivery of the

holistic platform. We highlight the functionalities of the OPTIMUM platform, broken



Page | 11


v.1.0, 28/12/2016

down into functionalities provided to the two target end user categories of the

platform, namely users of the OPTIMUM mobile application, and users of the OPTIMUM

web application. We provide the sequence diagram of each functionality, highlighting

the individual components which have been integrated in order to support the

functionality. In turn, we document the technical interfaces between the various

components interacting in order to support the functionality, providing the technical

details that guided the integration efforts.

Chapter 3 documents the installation instructions required in order to set up the

OPTIMUM platform and operate it outside the context of the project. Within the

context of the current deliverable, we document the pre-requisites for deploying each

component, along with the deployment scripts and commands for its execution.

Chapter 4 documents the Software Quality Assurance Plan, the aim of which is to

provide a single point of reference on the SW quality that will be governed during the

course of the project.

Chapter 5 concludes the deliverable.



Page | 12


v.1.0, 28/12/2016

2 OPTIMUM Integrated Platform Chapter 2 highlights the functionalities of the OPTIMUM platform, broken down into

functionalities provided to the two target end user categories of the platform, namely users of

the OPTIMUM mobile application, and users of the OPTIMUM web application. The users of the

OPTIMUM mobile application correspond to the users involved in the multimodal routing use

cases and the motorhome use case. The users of the OPTIMUM web interface correspond to

the freight operators which – always in collaboration with the road operators – can benefit

from the dynamic charging scenario that has been analysed in deliverable D1.3.

The current chapter has been broken down into two main sub-chapters as per the target end

user categories. In each sub-chapter, we provide the sequence diagram of the functionality to

be supported as per the corresponding use case that has been documented in D1.3,

highlighting the individual components as these have been documented in the technical

architecture in D6.1, which have been integrated in order to support the functionality. In turn,

we provide a series of tables which document the technical interfaces between the various

components interacting in order to support the functionality, providing the technical details

that guided the integration efforts.

Note: It is not the scope of the current deliverable to provide screenshots of users interacting

with the OPTIMUM applications (mobile application and web interface), since this is the scope

of D6.2 where the actual applications are delivered as prototypes and as reports. The scope of

the current chapter is to highlight how the discrete components have been integrated into a

holistic platform and how they inter-operate in order to facilitate these functionalities.

2.1 OPTIMUM Mobile Application Functionalities The current subchapter highlights the functionalities of the OPTIMUM platform, from the

perspective of the users of the OPTIMUM mobile application. These main functionalities have

been extracted from D1.3 where the various use cases are documented, and include:

The registration of the mobile application user.

The selection of the mobility preferences

The planning of a trip

The management / modification of a trip, triggered by the system

The planning of a route for motorhome users and

The evaluation of the application.



Page | 13


v.1.0, 28/12/2016

2.1.1 Registration

The first functionality regards the registration of the user at the OPTIMUM mobile application.

The user downloads the mobile application and installs it in order to use it for the first time. The

user interacts directly with the interface of the mobile app. The user fills in the registration

details through this interface, and the registration details are passed from the mobile app to

the OPTIMUM mobility hub and from there on to the OPTIMUM repository in order for them to

be stored. Upon the successful registration of the user the mobility hub sends a confirmation to

the mobile app which is displayed on the interface of the mobile app in order to notify the user

that the registration has been completed successfully. The user registration functionality in

terms of information exchange among the various components interoperating in order to

support it, is graphically illustrated in the sequence diagram depicted in Figure 1.

Figure 1: OPTIMUM Mobile App User Registration

As is depicted in the sequence diagram, the specific functionality supports one main technical

interface, that between the mobile app and the mobility hub. The details of this technical

interface are documented in Table 1.



Page | 14


v.1.0, 28/12/2016

Table 1: OPTIMUM mobile-app User Registration –mobile-app/mobility-hub interface

Technical Interface

Reference Code UR#01

Function Send registration details + Confirm registration

Subsystems mobile-app, oauth-provider

Type, State

RESTfull-API, Synchronous

REGISTRATION USING WEB INTERFACE

Endpoint URI (UI)

[GET] https://accounts.nissatech.com/optimum/registration

Input Data

HTML form that requires username and email as inputs

Output Data

HTML Confirmation page + email with password reset code

REGISTRATION USING REST API

Endpoint URI (user registration)

[POST] https://api.nissatech.com/optimum/oauth/v2/new-user

Input Data

{“username”: “<String>”,”email”: “<String>”}

Output Data

{“registrationCode”: “<random-string>”}

Endpoint URI (password reset)

[POST] https://api.nissatech.com/optimum/oauth/v2/password-reset

Input Data

{“registrationCode”:“<random_string>”,“password”:”<String>”,“confirmPassword”,“<String>”}

https://accounts.nissatech.com/optimum/registration

https://api.nissatech.com/optimum/oauth/v2/new-user

https://api.nissatech.com/optimum/oauth/v2/password-reset



Page | 15


v.1.0, 28/12/2016

Output Data

{ “username”: “<String>”, ”email”: “<String>”, “name”: { “firstName”: “<String>” “middleName”: “<String>” “familyName”: “<String>” } }

2.1.2 Mobility Preferences Selection

The second functionality regards the selection of mobility preferences of the user and the

creation of his/her profile in order for OPTIMUM to be able to customise the persuasive

strategies and in general provide a more personalised experience in terms of route and

transportation suggestions. The user launches the OPTIMUM mobile application for the first

time, and interacts directly with its interface. The user is presented with a (series of)

questionnaires which s/he is prompted to fill in. The user fills in the questionnaires and the

replies are passed from the mobile app to the OPTIMUM mobility hub and from there on to the

OPTIMUM repository in order for them to be stored.

Figure 2: OPTIMUM Mobility Preferences Selection

The recommender retrieves the replies of the user from his/her personal profile in order to

build the persuasion strategy to be used in the future trip plans. This process is of course

transparent to the user. The mobility preferences selection functionality in terms of



Page | 16


v.1.0, 28/12/2016

information exchange among the various components interoperating in order to support it, is

graphically illustrated in the sequence diagram depicted in Figure 2.




Table 2: OPTIMUM Mobility Preferences selection –mobile-app/mobility-hub interface

Technical Interface

Reference Code MP#01

Function Send questionnaire details to be stored in repository

Subsystems mobile-app, mobility-hub

Type, State

HTTP-Request, Synchronous

Endpoint URI

Mobility Hub: HTTP POST http://test-optimum.fluidtime.com:8080/route/user/profile/init Repostitory euprojects.net:3368 Repository: Mongo-DB, Collection OptiumumUsers (JAVA spring-data-mongodb)

Input Data

JSON Object public class InitialProfile { @serializedname("gender") private InitialProfile.GenderEnum gender = null; @serializedname("age") private Integer age = null; @serializedname("numberOfChildren") private Integer numberOfChildren = null; @serializedname("carOwnership") private Integer carOwnership = null; @serializedname("bikeOwnership")



Page | 17


v.1.0, 28/12/2016

private Boolean bikeOwnership = null; @serializedname("motorcycleOwnership") private Boolean motorcycleOwnership = null; @serializedname("education") private String education = null; @serializedname("occupation") private String occupation = null; @serializedname("q1") private Integer q1 = null; @serializedname("q2") private Integer q2 = null; @serializedname("q3") private Integer q3 = null; @serializedname("q4") private Integer q4 = null; @serializedname("q5") private Integer q5 = null; @serializedname("q6") private Integer q6 = null; @serializedname("q7") private Integer q7 = null; @serializedname("q8") private Integer q8 = null; @serializedname("q9") private Integer q9 = null; @serializedname("q10") private Integer q10 = null;

Output Data

HTTP-Status Code



Page | 18


v.1.0, 28/12/2016

2.1.3 Trip Planning

The third functionality regards the planning of a trip from a user. A trip plan request from a user

includes the selection of the origin and destination points, date and time when the trip will be

conducted, transportation means including own means (car, bicycle), shared means (car

sharing, bike sharing), public transportation means (train, buses, metro), as well as via-points,

namely points / places which should be included in the route.

Figure 3: OPTIMUM Trip Planning

The user logs in the OPTIMUM mobile application (and is authenticated by the OPTIMUM

security mechanism), navigates to the new route request menu and fills in all necessary details,

which were aforementioned. These trip preferences are passed from the mobile app to the

OPTIMUM mobility hub and from there on to the OPTIMUM multimodal router, in order for

them to be processed and a series of route alternatives to be generated for the specific time,



Page | 19


v.1.0, 28/12/2016

and origin and destination points. The OPTIMUM multimodal router interfaces with the

OPTIMUM traffic forecaster in order to retrieve traffic forecasts and use them in the generation

of routes.. This interaction is implemented through the central repository. The traffic forecaster

generates and stores forecasts for the different edges of the network graph used by the routing

engine. This is a recurring process that is executed at regular time intervals (e.g. 5 minutes).The

OPTIMUM multimodal router in turn returns the optimised multimodal routes to the mobility

hub. As has been explained, OPTIMUM integrates personalization mechanisms, thus the

optimised multimodal routes are not returned directly to the user through the interface of the

mobile app, but are passed on to the OPTIMUM recommender in order for the routes to be

personalised. Thus, the mobility hub sends to the OPTIMUM recommender the routes (along of

course with the user ID), and the OPTIMUM recommender ranks them and generates a

persuasive message to be returned to the user, in order for the user to select an eco-friendlier

route. The ranked, routes, along with the persuasive messages are passed on from the

OPTIMUM recommender to the OPTIMUM mobility hub, and from the hub to the OPTIMUM

mobile app, on the interface of which they are displayed for the user to select. Through the

interface of the OPTIMUM mobile app, the user is able to select a route and store it. The mobile

app then forwards the selected route to the OPTIMUM mobility hub which undertakes the

storage of the selected route under the specific user in the OPTIMUM repository. The trip

planning functionality in terms of information exchange among the various components

interoperating in order to support it, is graphically illustrated in the sequence diagram depicted

in Figure 3.

As is depicted in the sequence diagram, the specific functionality supports several technical

interfaces, the details of which are documented in the tables that follow.

The trip preferences (origin and destination points, date and time when the trip will be



namely points / places which should be included in the route) are passed from the mobile app

to the OPTIMUM mobility hub. The details of this technical interface are documented in Table 3

(request) and Table 8 (response).

Table 3: OPTIMUM Trip Planning –mobile-app/mobility-hub interface

Technical Interface

Reference Code TP#01

Function Send trip planning request




Page | 20


v.1.0, 28/12/2016

Type, State

HTTP-POST- Request, Synchronous

Endpoint URI

http://test-optimum.fluidtime.com:8080/route

Input Data

JSON ariadne-json-route-format1

Output Data

JSON ariadne-json-route-format

The aforementioned trip preferences are passed from the OPTIMUM mobility hub on to the

OPTIMUM multimodal router, in order for them to be processed and a series of route

alternatives to be generated for the specific time, and starting and destination points. The

details of this technical interface are documented in Table 4 (request) and Table 6 (response).

Table 4: OPTIMUM Trip Planning – mobility-hub/multimodal-router interface

Technical Interface


Function Request route, transportation modes and PT situation. Note: In the case of the Park & Ride and Park & Bus scenarios, information regarding own vehicle location is also included in the Trip Planning request without modifying the sequence diagram and implementation logic.

Subsystems mobility-hub, multimodal-router

Type, State

Type: A simple RESTful API with only two methods. One method is used to submit (POST) routing requests, and the other to retrieve (GET) the route computed. State: Synchronous, as the router computes the routes only upon request.

Endpoint URI

1 https://github.com/dts-ait/ariadne-json-route-format




Page | 21


v.1.0, 28/12/2016

http://62.218.45.10:8080/optimum/routes

Input Data

1) A JSON document following the “ariadne-json-route-format” (see https://github.com/dts-ait/ariadne-json-route-format/). Besides the obligatory “from” and “to” parameters (where the route must start and end), there are many other optional parameters that may be supplied, like departure or arrival time, the modes of transport that may be used, the location of a private car/bicycle, points of interest, or the walking speed. 2) Static data: the street and public transport network (including time tables) 3) Dynamic data (the current “state of the world”):

Where the free parking places, shared bicycles and shared cars are

Delays in the public transportation network

Forecasts for the street network (see output of Table 5)

Output Data

The response to a routing request is the description of the route computed (according to the “ariadne-json-route-format”), containing enough information so that the route can be visually shown to the user.

The OPTIMUM multimodal router interfaces with the OPTIMUM traffic forecaster in order to

retrieve traffic forecasts for different segments and generate optimized multimodal routes. The

details of this technical interface are documented in Table 5.

Table 5: OPTIMUM Trip Planning –multimodal-router/traffic-forecaster interface

Technical Interface


Function Request traffic forecasts + Return traffic forecasts

Subsystems multimodal-router, traffic-forecaster

Type, State


Endpoint URI

TBC

Input Data

https://github.com/dts-ait/ariadne-json-route-format/




Page | 22


v.1.0, 28/12/2016

The input data can be an array of edges from the graphs used by the

routing engine.

[

{

"_id" : "305567607004_t",

"osmWay" : NumberLong(305567607),

"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817"

},

{

"_id" : "231366848002_f",


"fromLatLon" : "52.5346069,-1.9183908",

"toLatLon" : "52.5345726,-1.918588"

}

] Output Data

{

"_id" : "305567607004_t",


"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817",

"forecasts" : [

{

"timeStepStart" : ISODate("2016-12-14T10:00:00.000+0000"),

"timeStepEnd" : ISODate("2016-12-14T10:00:00.000+0000"),

"dataType" : "travelTime",

"value" : 6.456

},

{



"dataType" : "speed",

"value" : 16.456

},

{




"value" : 2.756

},

{




"value" : 23.456

}

]

}



Page | 23


v.1.0, 28/12/2016

The OPTIMUM multimodal router in turn returns the traffic forecasted routes to the mobility

hub (response to the request from Table 4). The details of this technical interface are

documented in Table 6.

Table 6: OPTIMUM Trip Planning –multimodal-router/mobility-hub interface

Technical Interface


Function Return traffic forecasted routes

Subsystems multimodal-router, mobility-hub

Type, State


Endpoint URI


Input Data

Same as in Table 4. Especially the forecasts for the street network are of particular importance. (see also output of Table 5)

Output Data


As has been explained, OPTIMUM integrates personalization mechanisms, thus the traffic

forecasted routes are passed on to the OPTIMUM recommender in order for the traffic

forecasted routes to be personalised. Thus, the mobility hub sends to the OPTIMUM

recommender the traffic forecasted routes (along of course with the user ID), and the

OPTIMUM recommender ranks the traffic forecasted routes generated by the OPTIMUM

multimodal router, and generates a persuasive message to be returned to the user, in order for

the user to select an eco-friendlier route. The ranked, traffic forecasted routes, along with the

persuasive messages are passed on from the OPTIMUM recommender to the OPTIMUM

mobility hub. The details of this technical interface are documented in Table 7.



Page | 24


v.1.0, 28/12/2016

Table 7: OPTIMUM Trip Planning –mobility-hub/recommender interface

Technical Interface


Function Request route ranking + Return sorted list of recommended routes and persuasive messages

Subsystems mobility-hub, recommender

Type, State

RESTfull-API

Endpoint URI

http://snf-697531.vm.okeanos.grnet.gr:8080/recommender/route_recommender

Input Data

Inputs: user_id: The OPTIMUM ID of the user; A list of alternatives routes in json format as shown in the following figure.



Page | 25


v.1.0, 28/12/2016

Output Data

A sorted list of recommended routes as shown in the following figure.

The OPTIMUM mobility hub passes on the ranked, routes, along with the persuasive messages

to the OPTIMUM mobile app, on the interface of which they are displayed for the user to

select. The details of this technical interface are documented in Table 8.

Table 8: OPTIMUM Trip Planning – mobility-hub/mobile-app interface

Technical Interface


Function Return ranked forecasted routes and persuasive messages. It is the response of TP#01

Subsystems mobility-hub, mobile-app



Page | 26


v.1.0, 28/12/2016

Type, State

Response of HTTP-POST-Request

Endpoint URI


Input Data


Output Data


Through the interface of the OPTIMUM mobile app, the user is able to select a route and store

it. The mobile app then forwards the selected route to the OPTIMUM mobility hub which

undertakes the storage of the selected route under the specific user in the OPTIMUM

repository. The details of this technical interface are documented in Table 9.

Table 9: OPTIMUM Trip Planning –mobile-app/mobility-hub interface

Technical Interface


Function Send selected route to be stored in repository by sending the trip id to mobility hub. The hub stores the trip in the Mongo DB


Type, State

HTTP POST Request, Synchronous

Endpoint URI

http://test-optimum.fluidtime.com:8080/user/trips/<trip-ID>

Input Data

Output Data

HTTP-Status Code




Page | 27


v.1.0, 28/12/2016

2.1.4 (System-Triggered) Trip Management

The fourth functionality regards the management of a trip from a user, when the user is

triggered to modify the trip based upon an event that has been identified by the OPTIMUM

platform which influences the route that the user has selected to follow.

Note #1: The specific use case requires that the user of the mobile application has already stored

a near-future route, or is currently executing a trip that has been suggested by the system. The

stored route is required for the platform to know where the user is currently located, and where

the user is heading, so as to identify whether the event recognized influences the user route.

Note #2: After the system notifies the user about the occurrence of an event, and the user

selects to modify the trip, whether current or near-future, the process is identical with the trip

planning scenario, since the user re-initiates the process to find an alternative route. The only

difference between the current and near future is that in the scenario where the user is on

route, the starting point will be the current location of the user as retrieved by the GPS of the

user’s device.

Let us assume that user A has already arranged a trip and is currently on route. The tracking

library that is integrated in the OPTIMUM mobile application is sending information regarding

the user (including the coordinates and the travel speed, as well as the UserID) per specific time

intervals. This information (and in general all future user-generated information captured by

the OPTIMUM mobile application) is sent from the OPTIMUM mobile application to the

OPTIMUM mobility hub, and from there on it is published to the OPTIMUM pub-sub

mechanism, for all subscribers to receive. Per specific time intervals, additional information is

also published to the OPTIMUM pub-sub mechanism, including for example traffic information

from the OPTIMUM traffic forecaster, information from raw data adapters (developed and

documented in the context of D2.4 and D2.5), weather information and in general information

that could be of value for the identification of events from the plethora of source which have

been analysed and documented in the context of WP2. This information is published on the

OPTIMUM pub-sub mechanism under specific topics. The OPTIMUM complex-event processor

(cep) is a subscriber to these topics, and receives all relevant information published, and

processes it in order to identify probable events. For example, an unexpected slowing down of

a number of users along a specific road segment, combined with bad weather but good traffic

conditions in nearby areas and normal public transport conditions could signify a traffic event

having occurred within that segment. Once the OPTIMUM cep identifies a probable event, it

publishes the corresponding information to the OPTIMUM pub-sub mechanism under the

corresponding specific topic. This event could affect user A (along with a plethora of other

users) who based upon the trip plan is heading towards the road segment affected by the



Page | 28


v.1.0, 28/12/2016

identified event. The OPTIMUM recommender is a subscriber to the cep_events topic of the

pub-sub mechanism, and listens to it so as to identify the users that are affected by the

identified event, based upon the trip plan that is stored in the OPTIMUM repository and the

current position of the user. If the OPTIMUM recommender deduces that (the trip of) a user (or

a number of users) is affected by the identified event from the OPTIMUM cep, then it sends the

ID of the user(s) affected along with the corresponding notification text to the OPTIMUM

mobility hub, so that this information is forwarded to the user. The OPTIMUM mobility hub

passes on the notification message regarding the identified event to the OPTIMUM mobile app,

which it is displayed to the user. From then on, the user can select to modify the trip, and the

process is identical with the trip planning scenario, since the user re-initiates the process to find

an alternative route. The only difference between the current and near future is that in the

scenario where the user is on route, the starting point will be the current location of the user as

retrieved by the GPS of the user’s device.

Figure 4: OPTIMUM (System-Triggered) Trip Management



Page | 29


v.1.0, 28/12/2016

The trip planning functionality in terms of information exchange among the various

components interoperating in order to support it, is graphically illustrated in the sequence

diagram depicted in Figure 4. As is depicted in the sequence diagram, the specific functionality

supports several technical interfaces, the details of which are documented in the tables that

follow.

Let us assume that the user A has already arranged a trip and is currently on route. The tracking

library that is integrated in the OPTIMUM mobile application is sending information regarding

the user (including the coordinates and the travel speed, as well as the UserID) per specific time

intervals. This information (and in general all future user-generated information captured by

the OPTIMUM mobile application) is sent from the OPTIMUM mobile application to the

OPTIMUM mobility hub, and from there on it is published to the OPTIMUM pub-sub

mechanism, for all subscribers to receive. The details of this technical interface are documented

in Table 10.

Table 10: OPTIMUM (System-Triggered) Trip Management – mobility-hub/pub-sub-

mechanism interface

Technical Interface

Reference Code TM#01a

Function Publishes GPS tracking data (coordinates, speed)

Subsystems Mobility-hub, pub-sub-mechanism

Type, State

RESTfull-API (and mobile libraries) for collection, Asynchronous RabbitMQ connection for publish

Endpoint URI

traffic.ijs.si/NextPin/?user=<token>

Input Data

{user:”X”, location:{lat:#, lon:#, timestamp: ####, speed: #, accuracy:#, bearing:#, altitude: #}}

Output Data

{user:”X”, location:{lat:#, lon:#, timestamp: ####, speed: #, accuracy:#, bearing:#, altitude: #}}



Page | 30


v.1.0, 28/12/2016

Per specific time intervals, additional information is also published to the OPTIMUM pub-sub

mechanism, including for example traffic information from the OPTIMUM traffic forecaster,

information from raw data adapters (developed and documented in the context of D2.4 and

D2.5), weather information and in general information that could be of value for the

identification of events from the plethora of source which have been analysed and documented

in the context of WP2. This information is published on the OPTIMUM pub-sub mechanism

under specific topics. The details of this technical interface are documented in Table 11 and

Table 12.

Table 11: OPTIMUM (System-Triggered) Trip Management – raw-data-adapters/pub-sub-

mechanism interface

Technical Interface

Reference Code TM#01b

Function Publishes raw data (e.g. coordinates and the travel speed)

Subsystems raw-data-adapters, pub-sub-mechanism

Type, State

e.g. RESTfull-API, Synchronous

Endpoint URI

http://traffic.ijs.si/API/optimum_harmonized/

Input Data

(OPTION)?country=(COUNTRY)&(other inputs depending on the OPTION) OPTION:

sensors: o token: Specific user token; o sensor_type: counter, toll, simulated o road_type: highway, national o country;

sensor_values: o token: Specific user token; o country; o sensorId: ID for the sensor in the section; o year; o month; o day



Page | 31


v.1.0, 28/12/2016

weather: o token: Specific user token o country; o city (optional); o year; o month; o day

Output Data

sensors output example: { "_id" : ObjectId("56ab5c569f6ed594781cc00f"), "concession_name" : "EP Grande Porto (ex AEDL)", "road_name" : "A1", "road_type" : "highway", "sensor_type" : "counter", "km_point" : 297.0, "sensor_id_holder" : "A1_297+975_CT3687_C", "section" : "Santo Ovideo - Coimbrões (A44) ", "state" : "active", "concession_holder" : "IP", "bearing" : "northbound", "country" : "pt", "location" : { "type" : "Point", "coordinates" : [ -8.607517, 41.11034 ] } }

sensor_values example output: { "_id" : ObjectId("57015e7c60a5dee6439d5133"), "sensor_id" : "A1_297+975_CT3687_C", "date_time" : ISODate("2015-01-01T00:10:00.000+0000"), "volume" : 178, "average_speed" : 76, "occupancy" : 12, "flow" : 2136, "readings" : [ { "type" : "flow", "value" : 0, "vehicle_class" : "optimum_pt_category_a" }, { "type" : "flow", "value" : 2088, "vehicle_class" : "optimum_pt_category_b" }, (...)



Page | 32


v.1.0, 28/12/2016

{ "type" : "average_speed", "value" : 80, }, ] }, (...)

Table 12: OPTIMUM (System-Triggered) Trip Management – traffic-forecaster/pub-sub-

mechanism interface

Technical Interface

Reference Code TM#01c

Function Publishes traffic data

Subsystems traffic-forecaster, pub-sub-mechanism

Type, State

e.g. RESTfull-API, Synchronous

Endpoint URI

N/A

Input Data

Traffic and Social Media data through various data adaptors

Output Data

Forecasted Traffic Data {

"osmWay" : 305567607,

"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817",

"forecasts" : [

{

"timeStepStart" : "2016-12-14T10:00:00.000+0000",

"timeStepDuration" : 5,


"value" : 16.456

},

{

"timeStepStart" : "2016-12-14T10:05:00.000+0000",

"timeStepDuration" : 5,


"value" : 23.456

}

]

}



Page | 33


v.1.0, 28/12/2016

Social Media {

"screen_name": "BeepBeepTraffic",

"tweetId": 709892790688354304,

"gmt_tweet_date": "2016-03-16T00:03:25.000+0000",

"highway_codes": ["A4185", "A34"],

"traffic_concepts": ["DELAY", "ROADWORKS", "REPAIRS"],

"classification": {

"class": "Good",

"probability": 0.7175781553408117

},

"sentiment": {

"class": "Negative",

"probability": 0.7175781553408117

}

}

Traffic Events {

"type" : "MaintenanceWorks",

"road" : "M202",

"bearing" : "bothWays",

"start_date_time" : "2016-05-05T07:00:00.000+0000",

"end_date_time" : "2016-10-28T16:00:00.000+0000",

"location" : {

"type" : "Point",

"coordinates" : [

41.7063924033925,

-8.80627789033159

]

},

"source" : "IP",

"version" : "1",

"severity" : "unknown",

"probabilityOfOccurrence" : 1

}

The OPTIMUM complex-event processor (cep) is a subscriber to these topics, and receives all

relevant information published, and processes it in order to identify probable events. For

example, an unexpected slowing down of a number of users along a specific road segment,

combined with bad weather but good traffic conditions in nearby areas and normal public

transport conditions could signify a traffic event having occurred within that segment. Once the

OPTIMUM cep identifies a probable event, it publishes the corresponding information to the

OPTIMUM pub-sub mechanism under the corresponding specific topic. This event could affect

user A (along with a plethora of other users) who based upon the trip plan is heading towards

the road segment affected by the identified event. The details of this technical interface are

documented in Table 13 (subscription) and Table 14 (publication).



Page | 34


v.1.0, 28/12/2016

Table 13: OPTIMUM (System-Triggered) Trip Management – pub-sub-mechanism/cep

interface

Technical Interface

Reference Code TM#02

Function Is subscribed to aforementioned topics and collects related info

Subsystems pub-sub-mechanism, cep

Type, State

WEB Socket, Asynchronous

Endpoint URI

optimum.euprojects.net:8925 Exchange Name: “gps_data”

Input Data

{"id":"id","longitude":1.0,"latitude":2.0,"bearing":3.0,"speed":4.0,"timestamp":5}

Output Data

/

Table 14: OPTIMUM (System-Triggered) Trip Management – cep/pub-sub-mechanism

interface

Technical Interface


Function Publishes probable identified events

Subsystems cep , pub-sub-mechanism

Type, State

WEB Socket, Asynchronous

Endpoint URI



Page | 35


v.1.0, 28/12/2016

localhost:5672 Exchange name: “cep_issues”

Input Data

{"id":"id","longitude":1.0,"latitude":2.0,"bearing":3.0,"speed":4.0,"timestamp":5}

Output Data

{"event_type":"traffic_issue","location":[1.0,2.0],"timestamp":5,"issue_type":"slowdown","confidence": {"general":0.0,"bad_weather":0.0,"decreasing_speed":0.0,"social_media":0.0}} On CEP_ISSUES exchange

The OPTIMUM recommender is a subscriber to the cep_events topic of the pub-sub

mechanism, and listens to it so as to identify the users that are affected by the identified event,

based upon the trip plan that is stored in the OPTIMUM repository and the current position of

the user. The details of this technical interface are documented in Table 15.

Table 15: OPTIMUM (System-Triggered) Trip Management – pub-sub-mechanism/

recommender interface

Technical Interface


Function Is subscribed to cep-events topics and receives information related to events identified by cep

Subsystems pub-sub-mechanism, recommender

Type, State

RESTfull-API

Endpoint URI

The recommender subscribes to the OPTIMUM pub/sub middleware at: optimum.euprojects.net:8925

Input Data

The recommender listens for complex events of the following format: {

“event_type” : “traffic_issue”, “location” : [longitude, latitude], “time”: time_of_occurrence “issue_type”: type of the issue “confidence”: {



Page | 36


v.1.0, 28/12/2016

“general” : confidence_level, “bad_weather” : confidence_level, “decreasing_speed”: confidence_level, “social_media” : confidence_level }

} Output Data

N/A

If the OPTIMUM recommender identifies that (the trip of) a user (or a number of users) is

affected by the identified event from the OPTIMUM cep, then it sends the ID of the user(s)

affected along with the corresponding notification text to the OPTIMUM mobility hub, so that

this information is forwarded to the user. The details of this technical interface are documented

in Table 16.

Table 16: OPTIMUM (System-Triggered) Trip Management – recommender/mobility-hub

interface

Technical Interface


Function Sends notification regarding affected users by identified cep-events along with the corresponding notification text

Subsystems recommender, mobility-hub

Type, State

RESTfull-API

Endpoint URI


Input Data




Page | 37


v.1.0, 28/12/2016

Output Data




Page | 38


v.1.0, 28/12/2016

The OPTIMUM mobility hub passes on the notification message regarding the identified event

to the OPTIMUM mobile app, on the interface of which it is displayed to the user. The details of

this technical interface are documented in Table 17.

Table 17: OPTIMUM (System-Triggered) Trip Management – mobility-hub/mobile-app

interface

Technical Interface


Function Sends notification to the affected by the identified cep-events user, along with the corresponding notification text


Type, State



Page | 39


v.1.0, 28/12/2016

Firebase Cloud Messaging https://firebase.google.com/docs/cloud-messaging/ HTTP Post request

Endpoint URI

https://fcm.googleapis.com/fcm/send

Input Data

Body data: Content-Type:application/json Authorization: GOOGLE TOKEN { "data": { "type": "INFO|CHANGE|NEW", "message": "anyString (info, change, new)", "tripId": "anyString - optional (change)", "userId": "anyString - (info, change, new)", "location_name": "anyString - (new) ", "location_coordinates": "anyDouble;anyDouble (new)" } }, “to”: USER-TOKEN

Output Data

HTTP response (e.g. 200)

From then on, the user can select to modify the trip, and the process is identical with the trip

planning scenario, since the user re-initiates the process to find an alternative route. The only

difference between the current and near future is that in the scenario where the user is on

route, the starting point will be the current location of the user as retrieved by the GPS of the

user’s device. The trip preferences (starting and destination points, date and time when the trip

will be conducted, transportation means including own means (car, bicycle), shared means (car


namely points / places which should be included in the route) are passed from the mobile app

to the OPTIMUM mobility hub. The details of this technical interface are documented in Table

18 (request) and Table 23 (response).

https://firebase.google.com/docs/cloud-messaging/

https://fcm.googleapis.com/fcm/send



Page | 40


v.1.0, 28/12/2016

Table 18: OPTIMUM (System-Triggered) Trip Management –mobile-app/mobility-hub

interface

Technical Interface


Function Send trip planning (modification) request In order to modify a trip, a new route request is sent


Type, State

2 x HTTP-POST- Request, Synchronous (with delete in header for the trip-id)

Endpoint URI

http://test-optimum.fluidtime.com:8080/user/trips/<trip-ID> http://test-optimum.fluidtime.com:8080/route

Input Data


Output Data





details of this technical interface are documented in Table 19 (request) and Table 21

(response).

http://test-optimum.fluidtime.com:8080/user/trips/%3ctrip-ID




Page | 41


v.1.0, 28/12/2016

Table 19: OPTIMUM (System-Triggered) Trip Management – mobility-hub/multimodal-

router interface

Technical Interface


Function Request route, transportation modes and PT situation. Note: In the case of the Park & Ride and Park & Bus scenarios, information regarding own vehicle location is also included in the Trip Planning request without modifying the sequence diagram and implementation logic.


Type, State


Endpoint URI


Input Data



Delays in the public transportation network Forecasts for the street network (see output of Table 5)

Output Data



retrieve traffic forecasts for the specific segments which may influence the results returned to





Page | 42


v.1.0, 28/12/2016

the user. The OPTIMUM traffic forecaster returns the traffic forecasts to the OPTIMUM

multimodal router. The details of this technical interface are documented in Table 20.

Table 20: OPTIMUM (System-Triggered) Trip Management –multimodal-router/traffic-

forecaster interface

Technical Interface




Type, State


Endpoint URI

TBC

Input Data


routing engine.

[

{

"_id" : "305567607004_t",


"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817"

},

{

"_id" : "231366848002_f",


"fromLatLon" : "52.5346069,-1.9183908",

"toLatLon" : "52.5345726,-1.918588"

}

] Output Data

{

"_id" : "305567607004_t",


"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817",

"forecasts" : [

{




Page | 43


v.1.0, 28/12/2016



"value" : 6.456

},

{




"value" : 16.456

},

{




"value" : 2.756

},

{




"value" : 23.456

}

]

}




Table 21: OPTIMUM (System-Triggered) Trip Management –multimodal-router/mobility-

hub interface

Technical Interface




Type, State


Endpoint URI



Page | 44


v.1.0, 28/12/2016


Input Data

Same as in Table 4. Especially the forecasts for the street network are of particular importance. (see also output of Table 5)

Output Data



forecasted routes are not returned directly to the user through the interface of the mobile app,

but are passed on to the OPTIMUM recommender in order for the traffic forecasted routes to

be personalised. Thus, the mobility hub sends to the OPTIMUM recommender the traffic

forecasted routes (along of course with the user ID), and the OPTIMUM recommender ranks

the traffic forecasted routes generated by the OPTIMUM multimodal router, and generates a


route. The ranked, traffic forecasted routes, along with the persuasive messages are passed on

from the OPTIMUM recommender to the OPTIMUM mobility hub. The details of this technical


Table 22: OPTIMUM (System-Triggered) Trip Management –mobility-hub/recommender

interface

Technical Interface

Reference Code TP#11 (Similar to Table 7)



Type, State

RESTfull-API

Endpoint URI


Input Data



Page | 45


v.1.0, 28/12/2016


Output Data




Page | 46


v.1.0, 28/12/2016

The OPTIMUM mobility hub passes on the ranked, traffic forecasted routes, along with the

persuasive messages to the OPTIMUM mobile app, on the interface of which they are displayed

for the user to select. The details of this technical interface are documented in Table 23.

Table 23: OPTIMUM (System-Triggered) Trip Management – mobility-hub/mobile-app

interface

Technical Interface


Function Return ranked forecasted routes and persuasive messages It is the direct response of TM#07


Type, State



Page | 47


v.1.0, 28/12/2016


Endpoint URI


Input Data


Output Data






Table 24: OPTIMUM (System-Triggered) Trip Management –mobile-app/mobility-hub

interface

Technical Interface


Function Send selected route to be stored in repository


Type, State


Endpoint URI


Input Data

Output Data





Page | 48


v.1.0, 28/12/2016

2.1.5 Motorhome Route Planning

The motorhome route planning functionality regards the planning of a route, whether an

intercity one, or more probably a cross-border route from a motorhome driver. In its concept,

this specific scenario does not differ much from the more general trip planning scenario, with

the exception that this scenario mainly revolves around the utilization of an own vehicle

(motorhome) and not so much on the utilization of public transport, and also gives more

emphasis on the inclusion of via points, namely points / places which should be included in the

route, and the indication of Points of Interest (POIs) throughout the route which can also be

handled as via-points by the motorhome driver.

However, this scenario could also be expanded in order to include Park & Ride functionalities.

Namely, the motorhome driver can select a parking place in the city comprising the origin

point, where the motorhome is parked, and also select a parking space near the center of the

destination city, where the driver could park the motorhome, and from there on select public

transportation means or sharing means in order to reach the city center. However, these are

extensions to the scenario which expand its functionality without however including

modifications from the generic trip planning scenario.

Much like the case of the trip planning scenario, the motorhome route planning scenario

includes the selection of the origin and destination points, date and time when the trip will be



namely points / places which should be included in the route. The motorhome users need to

also indicate in the application that they will be using a motorhome, and have the option of

including POIs as via points through which they can pass. The POIs are indicated in the map and

include camping stations, gas stations, resting areas, or even sightseeing spots through which

the motorhome users may select to pass. Regardless of their nature, POIs, via points and stop-

overs are horizontally handled by the OPTIMUM platform as coordinates which should be

included in the suggested routes.

The user logs in the OPTIMUM mobile application (and is authenticated by the OPTIMUM

security mechanism), and interacts directly with its interface. The user navigates to the new

route request menu and fills in all necessary details, which were aforementioned. These route

preferences are passed from the mobile app to the OPTIMUM mobility hub and from there on

to the OPTIMUM multimodal router, in order for them to be processed and a series of route


OPTIMUM multimodal router interfaces with the OPTIMUM traffic forecaster in order to




Page | 49


v.1.0, 28/12/2016


multimodal router, which in turn returns the traffic forecasted routes to the mobility hub.

Figure 5: OPTIMUM Motorhome Route Planning








route. Specifically in the case of motorhome route planning, where the main means of

transportation of the user is the own vehicle, the recommendation is based on the levels of

CO2 emissions. The alternative with the least emissions is the most favorable. The ranked,

traffic forecasted routes, along with the persuasive messages are passed on from the

OPTIMUM recommender to the OPTIMUM mobility hub, and from the hub to the OPTIMUM



Page | 50


v.1.0, 28/12/2016

mobile app, on the interface of which they are displayed for the user to select. Through the

interface of the OPTIMUM mobile app, the user is able to select a route and store it. The mobile

app then forwards the selected route to the OPTIMUM mobility hub which undertakes the

storage of the selected route under the specific user in the OPTIMUM repository. The trip

planning functionality in terms of information exchange among the various components

interoperating in order to support it, is graphically illustrated in the sequence diagram depicted

in Figure 5.

As is depicted in the sequence diagram, the specific functionality supports several technical


The trip preferences (starting and destination points, date and time when the trip will be


sharing, bike sharing), public transportation means (train, buses, metro) and mainly own

motorhome, as well as via-points, stop-overs and POIs namely points / places which should be

included in the route) are passed from the mobile app to the OPTIMUM mobility hub. The


(response).

Table 25: OPTIMUM Motorhome Route Planning –mobile-app/mobility-hub interface

Technical Interface

Reference Code MRP#01

Function Send route planning request


Type, State


Endpoint URI


Input Data


Output Data




Page | 51


v.1.0, 28/12/2016





(response).

Table 26: OPTIMUM Motorhome Route Planning – mobility-hub/multimodal-router

interface

Technical Interface


Function Request route planning. The scenario is very similar to the Trip Planning, with the addition of stop-overs / via-points and POIs which could also constitute via-points. Transportation modes and PT situation are secondary in the specific scenario as motorhome route planning mainly regards inter-city or cross-border scenarios with own vehicles.


Type, State


Endpoint URI


Input Data




Output Data





Page | 52


v.1.0, 28/12/2016





multimodal router. Important note: The traffic forecaster can only work in the 3 pilot cities and

not outside of them since traffic data won’t be available. However, the interfacing can remain

since even if forecasts are not available for some areas, routes can be generated using static

information (e.g. speed limits). The details of this technical interface are documented in Table

27.

Table 27: OPTIMUM Motorhome Route Planning –multimodal-router/traffic-forecaster

interface

Technical Interface




Type, State


Endpoint URI

TBC

Input Data


routing engine.

[

{

"_id" : "305567607004_t",


"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817"

},

{

"_id" : "231366848002_f",




Page | 53


v.1.0, 28/12/2016

"fromLatLon" : "52.5346069,-1.9183908",

"toLatLon" : "52.5345726,-1.918588"

}

] Output Data

{

"_id" : "305567607004_t",


"fromLatLon" : "52.5593224,-1.6464245",

"toLatLon" : "52.5594063,-1.6458817",

"forecasts" : [

{




"value" : 6.456

},

{




"value" : 16.456

},

{




"value" : 2.756

},

{




"value" : 23.456

}

]

}






Page | 54


v.1.0, 28/12/2016

Table 28: OPTIMUM Motorhome Route Planning –multimodal-router/mobility-hub

interface

Technical Interface




Type, State


Endpoint URI


Input Data




Output Data


As it has been explained, OPTIMUM integrates personalization mechanisms, thus the traffic









Page | 55


v.1.0, 28/12/2016



route. Specifically in the case of motorhome route planning, where the main means of

transportation of the user is the own vehicle, the recommendation is based on the levels of

CO2 emissions. The alternative with the least emissions is the most favorable. The ranked,

traffic forecasted routes, along with the persuasive messages are passed on from the

OPTIMUM recommender to the OPTIMUM mobility hub. The details of this technical interface

are documented in Table 29.

Table 29: OPTIMUM Motorhome Route Planning –mobility-hub/recommender interface

Technical Interface

Reference Code MRP#05 (Similar to Table 7)



Type, State

RESTfull-API

Endpoint URI


Input Data




Page | 56


v.1.0, 28/12/2016

Output Data




Page | 57


v.1.0, 28/12/2016

The OPTIMUM mobility hub passes on the ranked, traffic forecasted routes, along with the

persuasive messages to the OPTIMUM mobile app (response to the request from Table 25), on

the interface of which they are displayed for the user to select. The details of this technical


Table 30: OPTIMUM Motorhome Route Planning – mobility-hub/mobile-app interface

Technical Interface


Function Return ranked forecasted routes and persuasive messages It is the response of MRP#01


Type, State




Page | 58


v.1.0, 28/12/2016

Endpoint URI


Input Data


Output Data






Table 31: OPTIMUM Motorhome Route Planning –mobile-app/mobility-hub interface

Technical Interface


Function Send selected route to be stored in repository


Type, State


Endpoint URI


Input Data

Output Data




Page | 59


v.1.0, 28/12/2016

2.1.6 Trip Evaluation

The trip evaluation functionality regards the evaluation of the OPTIMUM mobile application

from the user. The user interacts directly with the interface of the mobile app. The user fills in

the evaluation questionnaire through this interface, and the evaluation details are passed from

the mobile app to the OPTIMUM mobility hub and from there on to the OPTIMUM repository in

order for them to be stored. The trip evaluation functionality in terms of information exchange

among the various components interoperating in order to support it, is graphically illustrated in

the sequence diagram depicted in Figure 6.

Figure 6: OPTIMUM Trip Evaluation




Table 32: OPTIMUM Trip Evaluation –mobile-app/mobility-hub interface

Technical Interface

Reference Code TE#01

Function Send trip evaluation results to be stored in repository


Type, State

HTTP Request, syncronous



Page | 60


v.1.0, 28/12/2016

Endpoint URI

http://test-optimum.fluidtime.com:8080/user/feedback

Input Data

JSON Feedback

Output Data

HTTP Code (e.g. 200)



Page | 61


v.1.0, 28/12/2016

2.2 OPTIMUM Web Interface Functionalities The current subchapter highlights the main functionality of the OPTIMUM platform, from the

perspective of the users of the OPTIMUM web interface, which regards the request for

discounted toll prices for a specific route. This functionality is entitled “Dynamic Charging” and

involves the employee of a freight operator, who is responsible for developing the routes for

the corporate trucks. This employee needs to develop the route of the fleet of trucks, taking

into consideration a plethora of parameters, including pick-up and drop-off locations, which are

out of the scope of OPTIMUM, as well as toll prices for the segments of the route for which the

truck driver will use the Highways. The business model and process is defined in the

corresponding use case in D1.3. A secondary functionality of the web interface is that of the

retrieval of the requests that have already been made.

2.2.1 Dynamic Charging

The dynamic charging functionality regards the calculation of discounted toll prices for the tolls

of a highway through which a truck of a corporate fleet will pass. The discount is calculated with

the use of the dynamic charging model which is defined in the context of D4.3 and is thus out of

the scope of the current document. The user logs in the interface and is authenticated by the

authentication mechanism. The user enters the query details, which include the road of the

highway through which the corporate truck will pass, and the entry and exit points along this

highway, and submits the request for the discounted prices for the specific tolls involved in the

route. The web interface communicates with the dynamic charging component (which

computationally implements the mathematically formulated dynamic charging model)

providing the current date and time, and the sections of the highway through which the truck

will pass. The dynamic charging component communicates with the dynamic charging API in

order to request traffic flows which it in turn uses in order to calculate the discounted toll

prices. The dynamic charging component then returns the calculated discounted prices to the

web interface where they are presented to the user, while they are also passed on to the

OPTIMUM repository in order for them to be stored. The dynamic charging functionality in

terms of information exchange among the various components interoperating in order to

support it, is graphically illustrated in the sequence diagram depicted in Figure 7.



Page | 62


v.1.0, 28/12/2016

Figure 7: OPTIMUM Dynamic Charging

As is depicted in the sequence diagram, the specific functionality supports two main technical


The discounted tolls query details (highway through which the corporate truck will pass, and

the entry and exit points along this highway) are passed from the web app to the OPTIMUM

dynamic charging component. The details of this technical interface are documented in Table

33 (request) and Table 35 (response).

Table 33: OPTIMUM Dynamic Charging –web-app/dynamic-charger interface

Technical Interface

Reference Code DC#01

Function Requests discounted prices based on traffic flows

Subsystems web-app, dynamic-charger

Type, State

RESTful GET Method, Synchronous

Endpoint URI



Page | 63


v.1.0, 28/12/2016

/v1/tariff?date={YYYY-MM-DD}&section_id={sectionID}

Input Data

N/A

Output Data

Ref. Table 35

The dynamic charging component communicates with the dynamic charging API in order to

request traffic flows which it in turn uses in order to calculate the discounted toll prices. The

details of this technical interface are documented in Table 34.

Table 34: OPTIMUM Dynamic Charging –dynamic-charger/dynamic-charging-API interface

Technical Interface


Function Accepts traffic flow requests depending on date and road section, and responds with the actual vehicle flows

Subsystems Data harmonization, data APIs, dynamic-charging-API

Type, State


Endpoint URI

http://traffic.ijs.si/API/optimum_harmonized/sensors http://traffic.ijs.si/API/optimum_harmonized/sensor_values

Input Data

sensors:

token: Specific user token;

sensor_type: counter, toll, simulated

road_type: highway, national sensor_values:

token: Specific user token;

country;

sensorId: ID for the sensor in the section;

year;

month;



Page | 64


v.1.0, 28/12/2016

day Example: http://traffic.ijs.si/API/optimum_harmonized/sensor_values?token=TOKEN&country=pt&sensorId= A1_297+975_CT3687_C&year=2015&month=1&day=1

Output Data

sensors example output: { "_id" : ObjectId("56ab5c569f6ed594781cc00f"), "concession_name" : "EP Grande Porto (ex AEDL)", "road_name" : "A1", "road_type" : "highway", "sensor_type" : "counter", "km_point" : 297.0, "sensor_id_holder" : "A1_297+975_CT3687_C", "section" : "Santo Ovideo - Coimbrões (A44) ", "state" : "active", "concession_holder" : "IP", "bearing" : "northbound", "country" : "pt", "location" : { "type" : "Point", "coordinates" : [ -8.607517, 41.11034 ] } }

sensor_values example output: { "_id" : ObjectId("57015e7c60a5dee6439d5133"), "sensor_id" : "A1_297+975_CT3687_C", "date_time" : ISODate("2015-01-01T00:10:00.000+0000"), "volume" : 178, "average_speed" : 76, "occupancy" : 12, "flow" : 2136, "readings" : [ { "type" : "flow", "value" : 0, "vehicle_class" : "optimum_pt_category_a" }, { "type" : "flow", "value" : 2088, "vehicle_class" : "optimum_pt_category_b" }, (...) { "type" : "average_speed", "value" : 80, }, ]



Page | 65


v.1.0, 28/12/2016

}, (...)

The dynamic charging component then returns the calculated discounted prices to the web

interface where they are presented to the user, while they are also passed on to the OPTIMUM

repository in order for them to be stored. The details of this technical interface are

documented in Table 35, as the response to request described in Table 33.

Table 35: OPTIMUM Dynamic Charging – dynamic-charger/web-app interface

Technical Interface


Function Returns discounted prices based on traffic flows

Subsystems dynamic-charger, web-app

Type, State

RESTful GET Method, Synchronous

Endpoint URI

/v1/tariff?date={YYYY-MM-DD}&section_id={sectionID}

Input Data

N/A

Output Data

[ [{ "Time": "00:00:00", "18": 1.0588, "Date": "2015-02-02" }], [{ "Time": "01:00:00", "18": 1.4108, "Date": "2015-02-02" }], [{ "Time": "02:00:00",



Page | 66


v.1.0, 28/12/2016

"18": 1.5713, "Date": "2015-02-02" }], ……….. [{ "Time": "22:00:00", "18": 1.1095, "Date": "2015-02-02" }], [{ "Time": "23:00:00", "18": 0.5741, "Date": "2015-02-02" }] ]



Page | 67


v.1.0, 28/12/2016

3 OPTIMUM Platform Installation The current chapter documents the installation instructions required in order to set up the

OPTIMUM platform and operate it outside the context of the project. Within the context of the

current deliverable, we document the pre-requisites for deploying each component, along with

the deployment scripts and commands for its execution.

3.1 OPTIMUM Platform Installation The tables that follow document the pre-requisites for deploying each component comprising

the OPTIMUM holistic platform, as these have been documented in D6.1, along with the

deployment scripts and commands for its execution

Table 36: OPTIMUM data harmonisation

OPTIMUM web application

Reference Code II-DH

Prerequisites JAVA 1.7, MAVEN 3.3

Build tools MAVEN

Deployment Scripts / Commands

mvn clean install

Running Endpoint N/A

Table 37: OPTIMUM security service


Reference Code II-SS

Prerequisites JAVA 1.8, Redis 3.2.6, PostgreSQL 9.2, configuration files, public/private key pair in DER format

Build tools


#!/bin/bash APP_PORT=9001 # configureService(appName, version, port, configFile, params)



Page | 68


v.1.0, 28/12/2016

function configureService { if [[ -z $1 || -z $2 || -z $3 || -z $4 ]]; then echo "FATAL ERROR: Bad configuration"; exit 1 fi APP_NAME=$1 FULL_NAME=$1-$2 DIR=./${FULL_NAME} PID_FILE=${DIR}"/RUNNING_PID" PORT=$3 CONFIG_FILE=$4 FRESH_INSTALL=$5 INIT=$6 echo "======================================================" echo " Setting UP "${FULL_NAME}" " echo "======================================================" if [ -f ${PID_FILE} ]; then PID=$(cat ${PID_FILE}) kill -9 $PID rm -f ${PID_FILE} echo "Process ["${PID}"] is killed" fi if [[ -n ${FRESH_INSTALL} && ${FRESH_INSTALL} == "all" ]]; then if [ -d ${DIR} ]; then rm -R -f ${DIR} echo "Directory "${DIR}" is removed" fi unzip ${FULL_NAME}.zip fi if [[ -n ${INIT} && ${INIT} == "init" ]]; then CONFIG_FILE="init.conf" fi if [ -f ${CONFIG_FILE} ]; then echo "Configuration files cloning..." cp -rf openid.conf ${DIR}/conf/ cp -rf ${CONFIG_FILE} ${DIR}/conf/ echo "[DONE]" fi nohup $DIR/bin/$APP_NAME -Dhttp.port=${PORT} -Dconfig.resource=${CONFIG_FILE} & echo "Application "$APP_NAME" is started" } rm -f nohup.out configureService oauth2_ui 1.0 ${APP_PORT} optimum_ui.conf $1 $2



Page | 69


v.1.0, 28/12/2016

# Wait 5 seconds, because UI server will need some time to start http provider echo "======== WAITING CONFIGURATION FROM FIRST SERVICE =========" sleep 5s #if [[ -n "echo $OPENID_CONF_URL" ]]; then # echo $HOME #fi export OPENID_CONF_URL="https://accounts.nissatech.com/optimum" export HTTP_CONTEXT="/optimum/oauth/v2/" export DB_URL="jdbc:postgresql://<postgres-url>" export DB_USER="oauth_u1" export DB_PASS="<POSTGRES DATABASE PASSWORD>" export REDIS_HOST="<REDIS_HOST_URL>" expost REDIS_PASS="<REDIS_MASTER_PASSWORD>" echo "Server OPENID url is set to: "$OPENID_CONF_URL echo "Server http context is:"$HTTP_CONTEXT mkdir ./oauth2_server-1.0/conf/ cp -R ./certs ./oauth2_server-1.0/conf/ configureService oauth2_server 1.0 $(( APP_PORT + 1)) production.conf $1 $2

Running Endpoint OAuth UI: https://accounts.nissatech.com/optimum/ OAuth API: https://api.nissatech.com/optimum/oauth/v2/

Table 38: OPTIMUM pub-sub-mechanism


Reference Code II-PS

Prerequisites Erlang

Build tools /


sudo service rabbitmq-server start

Running Endpoint http://optimum.euprojects.net:8925



Page | 70


v.1.0, 28/12/2016

Table 39: OPTIMUM cep


Reference Code II-CEP

Prerequisites JAVA 1.8

Build tools


nohup java -jar /home/pubsub/monitor/event_monitor-1.0-SNAPSHOT.jar &

Running Endpoint

Table 40: OPTIMUM traffic forecasting service


Reference Code II-TF

Prerequisites JAVA 1.8, PYTHON 2.7.11, R

Build tools N/A


Python classes:

Factory.py, RForecast.py, KalmanFilter.py, KerasMLP.py, mySVR.py, DataPreprocess.py, FactoryRegress.py, LinearRegression.py, randomForestRegression.py

Command for running the ML models of the forecasting engine

$ /home/optimum/ypet/pythonScritps/fulldata/models/exec.h

Running Endpoint TBC



Page | 71


v.1.0, 28/12/2016

Table 41: OPTIMUM social mining service


Reference Code II-SM

Prerequisites PYTHON 2.7.11, R, Shiny Server

Build tools N/A


Command for starting the Shiny Server on OPTIMUM’s VM

$ sudo start shiny-server

Commands for retrieving tweets using the Twitter Streaming API (from /home/optimum directory). Are being executed automatically every five minutes using cron jobs.

$ python twitter_streaming\Stream_UK_accounts.py

$ python twitter_streaming\Stream_WM_tweets.py

$ python twitter_streaming\Stream_SL_accounts.py

$ python twitter_streaming\Stream_SL_tweets.py

Commands for aggregating data from tweets.

$ python TwitterAggsIntra\generateTwitterMentions.py

$ python TwitterAggsIntra\generateTwitterAggs.py

$ python TwitterAggsIntra\generateTwitterAggsRL.py

Commands for training sentiment classification model and for using a persisted model to classify new tweets sentiments

$ python TwitterSentimentsScikitLearnSVM\WriteSentiTweetsForTrainingIntra.py

$ python TwitterSentimentsScikitLearnSVM\ClassifySentimentsUKAccountsMongoIntraDaysMTv2.py

Commands for extraction of Named Entities (Locations, Organizations, People) from raw tweets

$ python NERUKTrafficTweets\NerUKAccountsMongoIntraDaysMTv3.py

$ python NERUKTrafficTweets\NerWMTweetsMongoIntraDaysMTv3

Running Endpoint http://optimum.euprojects.net:3838/SocialMinerShinyApp/



Page | 72


v.1.0, 28/12/2016

Table 42: OPTIMUM multimodal routing service


Reference Code

Prerequisites Java 1.8, Maven 3.3, Wildfly 10.1

Build tools Maven


$ mvn –Pprod clean wildfly:deploy

Running Endpoint http://(serverIP):8080 (currently http://62.218.45.10:8080/)

Table 43: OPTIMUM recommendation service


Reference Code II-Re

Prerequisites JAVA 1.8, MAVEN 3.3, Apache Tomcat 8

Build tools MAVEN


$ mvn clean install

A war file is generated, which should be deployed to a tomcat servlet container.

Running Endpoint http://snf-697531.vm.okeanos.grnet.gr:8080

Table 44: OPTIMUM mobility-hub


Reference Code II-MH

Prerequisites JAVA 1.8, TOMCAT <7, SPRING 4.3

Build tools




Page | 73


v.1.0, 28/12/2016

$ mvn clean install

$ cd app

$ mvn spring-boot:run

Running Endpoint http://(serverIP):8080

Table 45: OPTIMUM tracking service


Reference Code II-TS

Prerequisites PostgreSQL + PostGis, Node.js

Build tools npm


$ cd server/spd install

$ npm install

$ node server.js

Running Endpoint http://traffic.ijs.si/NextPin/?user=<token>

Source https://github.com/JozefStefanInstitute/nextPin

Table 46: OPTIMUM dynamic charging service


Reference Code II-DC

Prerequisites R on Ubuntu Server 16.04 LTS

Build tools Does not apply


Installation of R on Ubuntu Server 16.04 LTS

sudo apt-get update



Page | 74


v.1.0, 28/12/2016

sudo apt-get install git

sudo apt-get dist-upgrade -y

sudo apt-get install -y r-recommended

sudo apt-get install -y r-cran-reshape r-cran-httpuv r-cran-jsonlite r-cran-rcurl

sudo apt-get install -y libssl-dev libcurl4-openssl-dev

Installation of Tariff REST Service

cd /home/ubuntu

# git clone <URL> into directory "/home/ubuntu/dynamic-charging-api/"

cd /home/ubuntu/dynamic-charging-api/R

sudo R --no-save --no-restore -f install_packages.R

sudo setcap 'cap_net_bind_service=+ep' /usr/lib/R/bin/exec/R

Run Tariff REST Service

cd /home/ubuntu/dynamic-charging-api/R

R --no-save --no-restore -f server.R

Install Tariff REST Service as systemd service

# adjust User and/or WorkingDirectory in dcapi.service, if needed

cd /home/ubuntu/dynamic-charging-api/systemd

sudo cp dcapi.service /etc/systemd/system

sudo systemctl daemon-reload

sudo systemctl enable dcapi.service

sudo systemctl start --no-block dcapi.service



Page | 75


v.1.0, 28/12/2016

Install daily Tariff Table Recalulation timer

cd /home/ubuntu/dynamic-charging-api/systemd

sudo cp dcrecalc.timer dcrecalc.service /etc/systemd/system

sudo systemctl daemon-reload

sudo systemctl enable dcrecalc.timer

sudo systemctl start --no-block dcrecalc.timer


Table 47: OPTIMUM web application


Reference Code II-WA

Prerequisites JAVA 1.8, MAVEN 3.3

Build tools MAVEN


$ mvn clean install

$ cd app

$ mvn spring-boot:run




Page | 76


v.1.0, 28/12/2016

Table 48: OPTIMUM watchdog

OPTIMUM watchdog

Reference Code

Prerequisites Java 1.7, Tomcat, Postgres

Build tools .war files are built in Eclipse (development mode)


$ service tomcat7 start

Running Endpoint http://95.87.154.145:8082/DataRetrieverServer/SpidersPage.jsp

Source https://github.com/intrasoftintl/optimum/tree/master/watchdog

Table 49: OPTIMUM API management console

OPTIMUM API management console

Reference Code

Prerequisites Node.js, MongoDB

Build tools npm


$ npm install

$ node bin/www

Running Endpoint http://euprojects.net:8910/info/getApiInfo http://traffic.ijs.si/API/info/getApiInfo

Source https://github.com/JozefStefanInstitute/LPPServer

http://euprojects.net:8910/info/getApiInfo



Page | 77


v.1.0, 28/12/2016

4 OPTIMUM Software Quality Assurance The purpose of the Software Quality Assurance Plan, is to provide a single point of reference on

the SW quality that will be governed during the course of the project. The current chapter

defines the SW quality control and quality assurance activities that will be carried out. It

ensures that standards, processes, and procedures are defined and their execution is

continuously monitored and improved. It is based on the definitions in D10.1 - Project

Handbook, Quality Plan & Risk Management Chapter 11 Software Development Plan. It details

the RUP- Construction Phase.

Nowadays, the quality measurement of software development has become increasingly

important. As in any technological project in scale, there is a need for a way to measure the

quality and how the work progresses, when different people have different access to the source

code. Although, quality is somewhat subjective attribute and understood differently by

different people, an independent organization, founded by the Software Engineering Institute

at Carnegie Mellon University and the Object Management Group, called Consortium for IT

Software Quality (CISQ2) [1] has defined a set of software structural quality characteristics. In

the “House of Quality” model, these are "What’s" that need to be achieved:

Reliability: An attribute of structural solidity. Reliability measures the level of risk and

the likelihood of potential application failures. It also measures the defects injected due

to modifications made to the software.

Efficiency: The source code is the element that ensure high performance once the

application is in run-time mode. Efficiency is especially important for applications in high

execution speed environments such as algorithmic or transactional processing where

performance and scalability are paramount.

Security: A measure of the probability of potential security breaches due to poor coding

practices or architecture. This kind of breaches increase the risk of critical vulnerabilities

that can damage a business.

Maintainability: Maintainability includes the concept of adaptability and portability. It is

very important to measure the maintainability for mission-critical applications, where

each change is driven by tight schedules and is important to remain responsive during

the changes. It is very crucial to keep maintenance costs under control.

Size: The sizing of source code is a software characteristic that obviously impacts

maintainability.

2 http://it-cisq.org/



Page | 78


v.1.0, 28/12/2016

4.1 SW Development Method In OPTIMUM, implementation of the components, models, tools, infrastructures to constitute

the final integrated OPTIMUM solution will be carried out within WPs 2-6, where the final

product will be integrated in WP6. These activities will concern months four (4) to month thirty-

one (31) of the project duration. Within the second year, focus will be set on the development

and internal testing of the constituting components/toolkits, whereas during the second half of

the second year and up to the end of M31 and of the whole project, emphasis will be given on

integration activities and the respective testing of the platform as a whole. The construction

phase will output two software releases following an incremental and iterative approach of

software development at M20 and M31.

In general, for WPs 2-5 an agile method will be applied. For the partners, different approaches

are currently in use (Scrum, Kanban or combinations = Scrumban).

Figure 8: Scrum Workflow

Scrum [2] is an iterative and incremental agile software development framework for managing

product development. A Sprint (or iteration) is the basic unit of development in Scrum. The

Sprint is a time boxed effort; that is, it is restricted to a specific duration. The duration is fixed in

advance for each Sprint and is normally between one week and one month.

Each Sprint starts with a Sprint Planning event that aims to define a Sprint Backlog, identify the

work for the Sprint, and make an estimated commitment for the Sprint goal. Each Sprint ends



Page | 79


v.1.0, 28/12/2016

with a Sprint Review and Sprint Retrospective that reviews progress to show to stakeholders

and identify lessons and improvements for the next Sprints.

Scrum emphasizes working product at the end of the Sprint that is really done. In the case of

software, this likely includes that the software has been fully integrated, tested and

documented, and is potentially shippable.

Kanban [3] is a method for managing knowledge work which balances the demand for work to

be done with the available capacity to start new work. Intangible work items are visualized to

present all participants with a view of the progress of individual items, and the process from

task definition to customer delivery. Team members "pull" work as they have capacity, rather

than work being "pushed" into the process when requested.

Figure 9: Kanban board

A Kanban team is only focused on the work that's actively in progress. Once the team

completes a work item, they pluck the next work item off the top of the backlog. The product

owner is free to re-prioritize work in the backlog without disrupting the team, because any

changes outside the current work items don't impact the team. As long as the product owner

keeps the most important work items on top of the backlog, the development team is assured



Page | 80


v.1.0, 28/12/2016

they are delivering maximum value back to the business. So, there's no need for the fixed-

length iterations you find in scrum.

A Kanban board is one of the tools that to implement the Kanban Method for a project. A

popular example of a Kanban board for agile or lean software development consists of: Backlog,

Development, Testing, Approval and Done columns.

Scrumban [4] is a method that emerges when teams employ Scrum as their chosen way of

working and use the Kanban Method as a lens through which to view, understand and

continuously improve how they work.

In the agile iterations the usage of the SW implementation process as described in chapter 4.2

is suggested and the SW quality artefacts as described in chapter 4.3 should be provided.

The process can be adapted depending on the type of deliverables (D.x.x) that have to be

provided for integration for WP6.

4.2 Software Implementation - Process flow This process flow for SW implementation describes the general process steps as a guideline to

ensure a high quality in software development. Depending on the SW to be delivered to the

project the relevant process steps should be followed. The design of the Software can be

managed via own design documents or also by any design documentation inside the source

code.



Page | 81


v.1.0, 28/12/2016

Input Action R

R = Responsible | A= Accountable | S = Support | I = Informed

Output A S IPhase

Imp

lem

en

tatio

n &

De

velo

pe

r T

est

ing

Software ImplementationU

pd

ate

de

taile

d d

esi

gn

TL WPL STM

Develop or update

detailed design to

cover approved

requirements

TL WPL STM

Refine or update

detailed design to

cover approved

requirements

Review and agree

detailed designWPL

TLWPL STM

PM

Detailed design

(sub system level)

Detailed design

(module level)

Implement or correct

implementation,

update detailed

design, if necessary

TL WPL

Create or update

unit tests, mockups,

stubs and drivers

TL WPL

Perform unit tests

Docu of

performed

unit tests

TL WPL

Detailed design

(sub system level)

Detailed

design

Agreed detailed

design

Detailed design

agreed?

yes

no

WPL WPL

Released

implementation plan

SW

Implementation

start reached

Approved

requirements

(D1.2 + D1.3)

Released

implementation plan

Approved

requirements

Current

detailed design

Released

implementation plan

Implemented

test SW

Implemented

software

Detailed

design

Implemented

test SW

Implemented

softwareImp

lem

en

tatio

n a

nd

de

velo

pe

r te

stin

g

no no



Page | 82


v.1.0, 28/12/2016

Input Action R

R = Responsible | A= Accountable | S = Support | I = Informed

Output A S IPhase

Imp

lem

en

tatio

n &

De

ve

lop

er

Te

stin

g

Software ImplementationIm

ple

me

nta

tio

n a

nd

de

ve

lop

er

testin

g

Perform code

quality checks

Docu of

code quality

checks

TL WPL QM

Released

implementation plan

Implemented

software

Perform build

integrationTL WPL

Perform developer tests

on build server and

document test results

Documentation of

performed

developer tests

TL WPL QM

Deliver code TL WPL

Criteria to build

on build server

met?

TL WPL

Implemented

software

Checked in

code incl. rev.

number, label,

sw-version,

detailed design

Built software incl.

build numberChecked in

code

yes

no

Built software incl.

build number

Released

implementation plan

Implemented

test SW

Developer test

end criteria met?

Aggregate and

approve software for

OPTIMUM integration

Current detailed

design

SW approved for

next test level

TL WPL

WPL WPL QMWPL6

PM

Released

implementation plan

Released

implementation plan

yes

no

Docu of all

performed

developer tests

T6.5 Continuous

Integration, Testing

and Refinement

Perform code

quality checks

on build server

Docu of

code quality

checks

TL WPL

Released

implementation plan

Built

software

Figure 10: Software Implementation Process



Page | 83


v.1.0, 28/12/2016

4.3 SW Quality Artefacts In this SW implementation process some artefacts are defined to guarantee the software

quality for the delivered software.

This are the artefacts that are in consideration:

Design

SW Code

Code analysis

Unit Tests

Developer tests

Packaged, deployed SW

In the next chapters, you will find a description of possible quality assurance measures to each

artefact that should be considered to use in your development phase if applicable.

4.3.1 Design

To achieve a design with high quality it is recommended to follow some rules as listed below.

- Use standard templates for Detailed Design documentation

see as example Arc42 [5] with structuring in Building Block View, RunTime View,

Deployment View

- All Architectural and Design decisions have to be documented

- Generate API / interface documentation automatically from code whenever possible

4.3.2 SW Code

Description of the quality relevant topics:

All Deliverables (commented code, documentation, etc.) have to be written in English

Use of ALM tools is essential for source control (versioning), issue management

Write readable and testable code; interface-based design

Make use of SOLID principles

Use Design patterns and rules as much as possible (GoF, Fowler, KISS, YAGNI, DRY etc.)

Use “State-of-the-art” tooling & technologies

Perform Code Reviews for critical or complex code

4.3.2.1 SOLID principles

S.O.L.I.D [6] is an acronym for the first five object-oriented design (OOD) principles by Robert C.

Martin, popularly known as Uncle Bob. These principles, when combined together, make it easy

for a programmer to develop software that are easy to maintain and extend. They also make it



Page | 84


v.1.0, 28/12/2016

easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or

adaptive software development.

Table 50: S.O.L.I.D principles

Initial Stands

for Concept

S SRP

Single responsibility principle

a class should have only a single responsibility (i.e. only one potential

change in the software's specification should be able to affect the

specification of the class)

O OCP

Open/closed principle

“software entities … should be open for extension, but closed for

modification.”

L LSP

Liskov substitution principle

“objects in a program should be replaceable with instances of their

subtypes without altering the correctness of that program.” See also

design by contract.

I ISP

Interface segregation principle

“many client-specific interfaces are better than one general-purpose

interface.”

D DIP

Dependency inversion principle

one should “Depend upon Abstractions. Do not depend upon

concretions.”

* Remark: All artefacts out of the SW implementation phase (SW Code, documentation) have to

be stored and versioned in an adequate configuration management tool (e.g. Git, SVN).

Be aware that the target configuration management tool in the integration environment will be

Git and the delivered artefacts have be finally stored there.

4.3.3 Code Analysis

To find possible errors it is essential to start with verification/test as early as possible. The first

kind of verification is the code analysis with the goal to reduce possible error introduction and

to provide an efficient, maintainable code. For code analysis it is a must to use a static code

analyze tool like SonarQube or similar. The source code has to be verified against the

programming/coding rulesets for the appropriate language (for Sonar rulesets see

http://www.sonarsource.com/products/plugins/languages/). Constantly run analysis and

checks for violations in the code and remove these violations regarding required KPI´s (at least

no blocking or critical violations)

http://www.sonarsource.com/products/plugins/languages/



Page | 85


v.1.0, 28/12/2016

4.3.4 Unit Tests (module test)

For a high quality of the source code it is essential to perform unit tests with a high code

coverage. Unit tests have to be performed in the development environment to test the units

(classes, methods, functions) of a source code preferably under usage of appropriate unit

testing frameworks/tools like Junit (Java), NUnit (.Net),

Microsoft.VisualStudio.TestTools.UnitTesting etc. Deliverables to unit testing are:

Unit test - test cases

unit test reports (including test results summary)

Unit tests should run in each build in continuous integration in the SW implementation phase

(shown in figure3) for the developed code by WP2 to WP 5 if applicable.

4.3.5 Developer Tests

Developer tests have to be performed to test the developed and integrated OPTIMUM

component with her interfaces to other/external components. To test the OPTIMUM

component independently the external components have to be simulated (via mocks, stubs).

Test specifications and test cases have to be documented via adequate ALM/TM tools. The test

cases have to be referenced to the requirements or defects. Test Runs must be reproducible

and well documented (best via ALM/TM tool). A versioning of test cases and test data should be

possible. Test automation should be used were possible for regression testing. Developer tests

should be performed for each build in continuous integration in the SW implementation phase

(shown in figure3) by WP2 to WP 5 if applicable.

4.3.6 Packaged Deployed SW

Use continuous integration to guarantee that any change can be build and early integrated as

well tested. Therefore, include your unit tests in the build process. Build warnings should be

reduced to a minimum. Document how to configure, run and manage your SW-components. In

this regard document the necessary build environment, build-jobs, configuration as well

installation instructions. Look to it that also user manuals, handbooks etc. are part of your

package.

4.4 Software Quality ToolSet (recommended) Design: no special tool recommended

Configuration Management: Git(Hub) [7]

Unit Test : Junit (Java), NUnit (.Net), Microsoft.VisualStudio.TestTools.UnitTesting, =>

depending on programming language respectively development environment

Static Code Analysis: out of SonarQube or similar tools like Lint…



Page | 86


v.1.0, 28/12/2016

Build Management: Jenkins [8]

Development Tests: make use of a TestManagement-Tool (Tarantula, TestLink (Open Source) or

SPIRA, TTPro, Polarion, HP-ALM, TestRail (integrated in GitHub)

TA-Tools : no special tool recommended (e.g. Selenium…)

Bug-Tracking: GitHub Issue Tracking

Quality Assurance Platform: SonarQube [9]

o For project organisation, MAVEN [10] software tool should be employed. Apache Maven

is a software project management and comprehension tool. Based on the concept of a

project object model (POM), Maven can manage a project's build, reporting and

documentation from a central piece of information.

o For continuous integration, JENKINS software tool should be employed. Jenkins is an

award-winning application that monitors executions of repeated jobs, such as building a

software project or jobs run by cron. Among those things, current Jenkins focuses on the

following two jobs: 1) Building/testing software projects continuously, providing an

easy-to-use so-called continuous integration system, making it easier for developers to

integrate changes to the project, and making it easier for users to obtain a fresh build. 2)

Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even

those that are run on a remote machine.

o For version control, GIT software tool should be employed. Git is a free and open

source distributed version control system designed to handle everything from small to

very large projects with speed and efficiency. Git allows having multiple local branches

that can be entirely independent of each other.

o For quality assurance, SONAR (SONARQUBE) software tool should be employed.

SonarQube is an open platform to manage code quality. As such, it covers the 7 axes of

code quality: Architecture & Design, Duplications, Unit Tests, Complexity, Potential

Bugs, Coding Rules, Comments. SonarQube is a web-based application. Rules, alerts,

thresholds, exclusions, settings can be configured online. By leveraging its database,

SonarQube not only allows to combine metrics altogether but also to mix them with

historical measures.

o For bug tracking, GitHub Issue Tracker will be deployed. GitHub’s bug tracker is called

Issues, and has its own section in every repository.

https://wiki.jenkins-ci.org/display/JENKINS/Awards

https://git-scm.com/about/free-and-open-source

https://git-scm.com/about/free-and-open-source



Page | 87


v.1.0, 28/12/2016

4.5 SW Quality Monitoring and Controlling

4.5.1 Method and Tool

As a central controlling via SonarQube is not possible due legal reasons concerning source code

rights each partner has to set up his own SW quality tool set with SonarQube as quality

assurance tool to monitor and control the defined KPI´s/Metrics.

As programming/coding rulesets the existing set out of SonarQube for the used programming

language has to be used.

The results concerning the defined KPI´s/Metrics have to be delivered to the QM out of

SonarQube as Screenshot .

4.5.2 Defined KPI´s/Metrics

To reach an acceptable level of quality the goal for OPTIMUM project is to reach the following

described KPI´s when delivering to the integration environment.

This is the first set up for the metrics and the KPI´s. QM will evaluate continuous the results to

the metrics and adapt KPI´s if needed.

4.5.3 Source Code

Cyclomatic Complexity (number of linearly independent paths) < 10

Number of violations against coding guidelines (Critical, high, medium…) per component

o Critical = 0

o High = no threshold, but have to be resolved in time

o Medium: no treshold

Density of comment lines =

Comment lines / (Lines of code + Comment lines) * 100 : no special quality metric

But at least each function/component has to have an header with a description

Density of duplication = Duplicated lines / Lines * 100 < 10%

4.5.4 Unit Tests

100% passed unit tests

Condition Coverage = Branch Coverage by unit tests > 40% for new code

4.5.5 Bug Tracking

Number of bugs in development with severity critical or high when delivering to the

integration = 0



Page | 88


v.1.0, 28/12/2016

5 Conclusions The scope of the current document is to accompany the Integrated OPTIMUM Platform


platform. Within the context of this deliverable, the consortium highlighted the functionalities

of the OPTIMUM platform, broken down into functionalities provided to the two target end

user categories of the platform, namely users of the OPTIMUM mobile application, and users of

the OPTIMUM web application. These main functionalities for the user of the OPTIMUM mobile

application include: 1) The registration of the mobile application user, 2) the selection of the

mobility preferences, 3) the planning of a trip, 4) the management / modification of a trip,

triggered by the system, 5) the planning of a route for motorhome users and 6) the evaluation

of the application. From the perspective of the users of the OPTIMUM web interface, the main

functionality offered regards the request for discounted toll prices for a specific route, with a

side functionality offered being the retrieval of the requests that have already been made. For

each functionality we provided sequence diagrams, highlighting the individual components

which have been integrated in order to support the functionality. In turn, we document the

technical interfaces between the various components interacting in order to support the

functionality, providing the technical details that guided the integration efforts.

With regards to Quality Assurance, the consortium defined and documented the SW quality


standards, processes, and procedures are defined and their execution is continuously

monitored and improved. The consortium has opted for the adoption of the Scrumban method,

a method that emerges when teams employ Scrum as their chosen way of working and use the

Kanban Method to continuously improve how they work. The consortium has also defined

artefacts to guarantee the software quality for the delivered software, including: Design, SW

Code , Code analysis, Unit Tests, Developer tests and Packaged, deployed SW, and has also

defined the recommended Software Quality ToolSet to guarantee and upraise the quality of the

produced results.

Note: The testing results, as per the testing plan described in deliverable D6.1 and the software

quality assurance results as per the measures described in the current deliverable, will be

documented and analysed in deliverable D6.5.



Page | 89


v.1.0, 28/12/2016

6 References [1]. http://it-cisq.org/

[2]. https://www.scrumalliance.org/why-scrum

[3]. https://www.atlassian.com/agile/kanban

[4]. https://www.agilealliance.org/what-is-scrumban/

[5]. http://arc42.org/

[6]. https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

[7]. https://github.com/

[8]. https://jenkins.io/

[9]. http://www.sonarqube.org/

[10]. https://maven.apache.org/

http://it-cisq.org/

https://www.scrumalliance.org/why-scrum

https://www.atlassian.com/agile/kanban

https://www.agilealliance.org/what-is-scrumban/

http://arc42.org/

https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

https://github.com/

https://jenkins.io/

http://www.sonarqube.org/

https://maven.apache.org/

Documents

DELIVERABLE - optimumproject...JSI (Luka Bradesko, Zala Herga), NISSA (Nenad Stojanovic, Jovica Zlatanovic), FLU (Stephan Strodl), KAPSCH (Gabriel Makki, Rodrigo Barco) Integration