Integrated Service Description - TRIMIS...2013/01/28 · INFORMATION SOCIETY TECHNOLOGIES (IST) PROGRAMME IM@GINE IT IST-508008 Integrated Service Description Deliverable No. (use

INFORMATION SOCIETY TECHNOLOGIES (IST) PROGRAMME

IM@GINE IT

IST-508008

Integrated Service Description Deliverable No. (use the number indicated on technical annex)

D5.1.2

Workpackage No. WP5 Workpackage Title Service Delivery Platform Activity No. A5.1, A5.2, A5.3 Activity Title Interface to ticketing systems

Interfaces to GIS systems Integration, security issues and technical verification

Authors (per company, if more than one company provide it together)

M. Kauber (PTV) S. Zangherati, F. Protano (CRF) M. Raimondi, M. Manzato (MMS) N. Spanoudakis (SISO E. Bekiaris (HIT) V. Mizaras, T. Pachinis (TREDIT) F. Kolbay (TOPO) G. de Carolis (MOTOROLA) E. Kolokotroni (ICCS) B. Raichle (DC)

Status (F: final; D: draft; RD: revised draft):

F

File Name: IM@GINE IT D5.1.2_final.doc Project start date and duration 01 January 2004, 24 Months

IM@GINE IT Deliverable 5.1.2 Public Contract N. IST-508008

December 2005 ii PTV

Contents 1. Introduction ............................................................................................. 2 2. The IM@GINE IT service use cases ....................................................... 4

2.1. Global system use cases ........................................................................ 4 2.2. Italy ........................................................................................................... 9 2.3. Greece .................................................................................................... 10 2.4. Germany ................................................................................................. 11 2.5. Hungary .................................................................................................. 11 2.6. Finland .................................................................................................... 11

3. Global service architecture .................................................................. 13 3.1. Project global system architecture ....................................................... 13

3.1.1. Deployment scheme ....................................................................................... 13 3.1.2. Supported positioning technologies ................................................................ 14

3.2. Italian system architecture .................................................................... 14 3.3. Greek system architecture .................................................................... 16

3.3.1. Functional architecture ................................................................................... 17 3.3.2. Physical Architecture ...................................................................................... 19

3.4. German system architecture ................................................................. 20 3.5. Hungarian system architecture ............................................................. 22 3.6. Finnish system architecture.................................................................. 23

4. Interfaces and services in the test sites ............................................. 25 4.1. Service interfaces in Germany .............................................................. 25

4.1.1. Inter-Modal routing ......................................................................................... 26 4.1.2. Mapping and POI search ................................................................................ 29 4.1.3. Geocoding ...................................................................................................... 30 4.1.4. Traffic information ........................................................................................... 31 4.1.5. In-Door routing Web service ........................................................................... 32

4.1.5.1. Web Service Interface ................................................................................ 33 4.1.5.2. VISUM Interface ......................................................................................... 33

4.1.6. In-Car integration ............................................................................................ 35 4.2. Service interfaces in Italy ...................................................................... 36

4.2.1. MMS web services interfaces ......................................................................... 36 4.2.1.1. Geo-coding ................................................................................................ 37 4.2.1.2. Routing ...................................................................................................... 38 4.2.1.3. Mapping ..................................................................................................... 39 4.2.1.4. Traffic Information ...................................................................................... 40 4.2.1.5. POI search ................................................................................................. 42 4.2.1.6. Navigation service ...................................................................................... 43

4.2.2. to5T Web Service ........................................................................................... 45 4.3. Service interfaces in Greece ................................................................. 48

4.3.1. Inter-Modal routing ......................................................................................... 48 4.3.2. Mapping ......................................................................................................... 49 4.3.3. Geocoding ...................................................................................................... 49 4.3.4. POI services ................................................................................................... 50 4.3.5. Public transport timetables .............................................................................. 50 4.3.6. Flight information ............................................................................................ 50 4.3.7. Booking .......................................................................................................... 51 4.3.8. Cell-ID positioning .......................................................................................... 51


December 2005 iii PTV

4.4. Service interfaces in Finland ................................................................. 53 4.5. Service interfaces in Hungary ............................................................... 54

4.5.1. Geocoding service .......................................................................................... 55 4.5.2. Mapping service ............................................................................................. 55 4.5.3. Dynamic car, pedestrian, or public transport routing ........................................ 55 4.5.4. PT time table information ................................................................................ 55 4.5.5. Traffic information ........................................................................................... 55 4.5.6. Connect border ............................................................................................... 56 4.5.7. POI and event search ..................................................................................... 56

5. Multi Agent System and Ontology....................................................... 57 5.1. MAS Architecture ................................................................................... 57 5.2. Agents and Ontology ............................................................................. 60

6. Data Management Module .................................................................... 63 6.1. DMM System Design .............................................................................. 64

7. Nomad Device Application (NDA)........................................................ 65 7.1. NDA in general ....................................................................................... 65 7.2. JADE - LEAP Solution ........................................................................... 67 7.3. NDA for PDA ........................................................................................... 69 7.4. NDA for Smartphone.............................................................................. 69

8. Security of user data ............................................................................ 70 8.1. Introduction ............................................................................................ 70 8.2. Security parameters .............................................................................. 72 8.3. Security results ...................................................................................... 73

8.3.1. IM@GINE IT results ....................................................................................... 74 9. Service and platform integration and testing ..................................... 75

9.1. Introduction ............................................................................................ 75 9.2. Problems during integration ................................................................. 76 9.3. The IM@GINE IT testing cycle ............................................................... 77 9.4. Testing parameters ................................................................................ 78 9.5. Test plan ................................................................................................. 79 9.6. Testing results ....................................................................................... 80

9.6.1. Web services .................................................................................................. 80 9.6.1.1. 5T .............................................................................................................. 80 9.6.1.2. MMS .......................................................................................................... 80 9.6.1.3. PTV ............................................................................................................ 82 9.6.1.4. TOPOLIZ.................................................................................................... 86

9.6.2. MAS ............................................................................................................... 86 9.6.3. B2C Server ..................................................................................................... 87

9.6.3.1. User Profile Database Library ..................................................................... 88 9.6.4. NDA ............................................................................................................... 89

10. Conclusions .......................................................................................... 93 11. References ............................................................................................ 94 12. Annex : Integration Status Template................................................... 95


December 2005 iv PTV

List of figures Figure 1: Deployment scheme ................................................................................. 13 Figure 2: Italian in-car architecture .......................................................................... 15 Figure 3: Physical Architecture of Italian Site. .......................................................... 16 Figure 4: Greek pilot modules.................................................................................. 17 Figure 5: Functional Architecture of Greek Site. ...................................................... 19 Figure 6: Physical Architecture of Greek Site. ......................................................... 20 Figure 7: German system architecture ..................................................................... 22 Figure 8: Platform technical system architecture (POI Search example) ................. 25 Figure 9: Inner structure of a component ................................................................. 26 Figure 10: START element of the IMR interface ...................................................... 28 Figure 11: Inner structure of a component ............................................................... 30 Figure 12: Logical structure of the in-door service ................................................... 32 Figure 13: Example result of the in-door routing ...................................................... 34 Figure 14: Architecture of DC car ............................................................................ 35 Figure 15 MMS GIS platform functional architecture ............................................... 37 Figure 16 geo-coding SOAP request example ......................................................... 38 Figure 17 geo-coding SOAP response example ...................................................... 38 Figure 18 routing SOAP request example ............................................................... 39 Figure 19 mapping SOAP request example............................................................. 40 Figure 20 mapping SOAP response example .......................................................... 40 Figure 21 traffic information SOAP request example ............................................... 41 Figure 22 traffic information SOAP response example ............................................ 42 Figure 23 poi search SOAP request example .......................................................... 42 Figure 24 poi search SOAP response example ....................................................... 43 Figure 25: MMS Off Board Navigation Architecture ................................................. 44 Figure 26: to5T WS integration in MAS ................................................................... 45 Figure 27: 5T Park Info service Sample ................................................................... 46 Figure 28: 5T Traffic Info service Sample ................................................................ 47 Figure 29: 5T PT Timetable service Sample ............................................................ 47 Figure 30: Physical architecture for the positioning of the user ................................ 53 Figure 31: MAS architecture .................................................................................... 58 Figure 32: Federation of agents ............................................................................... 59 Figure 33: Invocation of a Web service by an agent ................................................ 62 Figure 34: Modular system design ........................................................................... 64 Figure 35: Nomad Device Application architecture .................................................. 66 Figure 36: Device SW architecture .......................................................................... 67 Figure 37: “Stand alone” execution mode ................................................................ 68 Figure 38: “Split” execution mode ............................................................................ 69 Figure 39: Security aspects at different levels ......................................................... 73


December 2005 v PTV

List of tables Table 1: Global Use Cases ........................................................................................ 9 Table 2: Italian Use Cases ...................................................................................... 10 Table 3: Greek Use Cases ...................................................................................... 10 Table 4: German Use Cases ................................................................................... 11 Table 5: Hungarian Use Cases................................................................................ 11 Table 6: Finish Use Cases ...................................................................................... 12 Table 7: Supported positioning technologies ........................................................... 14 Table 8: H/W equipment of the Greek site ............................................................... 16 Table 9: Hardware German GIS platform ................................................................ 20 Table 10: Hardware of Hungarian WS GIS platform ................................................ 22 Table 11: Details about 5T services......................................................................... 46 Table 12: Testing parameters .................................................................................. 79 Table 13: WS registered access and response time ................................................ 81 Table 14: WS percentage of usage and average response time.............................. 82 Table 15: Requests and their processing times (ms) on web service client and

server (EJB session) .............................................................................. 84 Table 16: Component execution times for an example corridor search request ....... 84


December 2005 vi PTV

List of abbreviations Term Explanation B2C Business to Customer CAN Controller Area Network COM Component Object Model COMAND On-board unit of DC test car CSI Common Service Interface DM Data Management Module EDS Embedded Development System EJB Enterprise Java Beans FIPA Foundation of Intelligent Physical Agents GIS Geographic Information System GPS Global Positioning System GPRS General Packet Radio Service GUI Graphical User Interface HAFAS Public transport information server of HACON HMI Human Machine Interface HTTP Hypertext Transfer Protocol IMAGE IMAGE Project IMR Inter-Modal Routing JADE Java Agent Development Framework JVM Java Virtual Machine J2ME Java 2 Micro Edition J2EE Java 2 Platform, Enterprise Edition JPEG Joint Photographic Experts Group (picture format) LBS Location Based Services LMP Logistics Mobility Platform MAC Apple Macintosh computer MAS Multi Agent System MCF Mobile Client Framework MIME Multipurpose Internet Mail Extensions MIDP Mobile Information Device Profile NDA Nomad Device Application OOSE Object Oriented Software Engineering OTA Open Travel Alliance OWL Web Ontology Language PC Personal Computer PDA Personal Digital Assistant POI Point Of Interest RDF Resource Description Framework RDFS Resource Description Framework Schema RMI Remote Method Invocation SOAP Simple Object Access Protocol SDLC Synchronous Data Link Control UC Use Cases UDDI Universal Description, Discovery and Integration UML Unified Modelling Language UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier URL Uniform Resource Locator WAP Wireless Application Protocol


December 2005 vii PTV

W3C World Wide Web Consortium WLAN Wireless Local Area Network WS Web Service (SOAP/XML) WSDL Web Services Description Language XML eXtensible Markup Language XSLT Extensible Stylesheet Language Transformations


December 2005 1 PTV

Executive Summary

The following document summarises the results of the work done in several work

packages. It gives a detailed overview over the final status of the system, its services

and content. This may differ between the test sites, since the representing

companies cover different areas of expertise and provide different content to feed the

services. The deliverable provides an overview over the different architectures and

services constellations implemented in the test sites. In addition, it provides

information on the Multi Agent System (as the business logic of the whole system),

and the mobile client application that will be used by the users.

Furthermore, the document covers issues regarding security and testing. It shows

how the testing environment is set up by each partner and how the results look like. It

also provides information on how the aspect of handling sensitive user data in a

secure manner was solved by the partners in the project.


December 2005 2 PTV

1. Introduction

The intention of this document is to provide a detailed overview over the final

implementation of the IM@GINE IT services. It is a summary of the work that has

been carried out in IM@GINE IT in WP1 to WP5, in its final phase and, in addition, of

the security and testing framework that was used during the integration process in

WP5. A short summary of the WPs 1-5 is provided below:

WP1 “Service Specification and System Architecture”: This WP dealt with the development of use cases and the analysis of user requirements. In addition it

specified the relevant services for the project and described the system architecture,

the ontology framework and the HMI.

WP2 “Service Development and Data Management”: The services of the project have been developed in this WP. The main work was related to the set-up of Web

services that represented the connection of the back-end with the agent platform

(MAS). The services are different, depending on what is available in the test sites. In

addition, user profile management and data management are included in this WP, as

well as the implementation of the ontology (in cooperation with WP3).

WP3 “Intelligent Agent Environment”: The main task of this WP was the development of the Multi Agent System (MAS). The MAS comprises different agents

that fulfil different tasks and are located on different levels of the system. Thus, in

addition to the MAS, the agents are also situated on the mobile device. The

integration of the ontology with the back-end Web services of the service providers

was also a major task of this WP. The MAS is the project’s “global” business logic.

WP4 “Nomad Device Applications”: This WP developed the HMI and the Nomad Device Application (NDA). The NDA is located on the users’ mobile device and offers

interfaces to the MAS and the external services, such as WLAN and Bluetooth. The

NDA is the project’s business logic on the mobile device.

WP5 “Service Delivery Platform”: This WP dealt with the integration of the different services and modules in the architecture, including mobile devices and in-car units.

This document is an outcome of this WP. In addition this WP includes the system

testing and the security issues of the project.


December 2005 3 PTV

As imaginable from the information above, this document connects WPs 1- 4 in their

final implementation status, and thus offers a comprehensive overview over the

IM@GINE IT system. In addition, it describes the results of the work performed in

WP5.

Further information on single WPs achievements and the NDA, can be found at the

relevant documents that have been produced in the individual WPs, in the past.


December 2005 4 PTV

2. The IM@GINE IT service use cases

The Use Cases described in the following sub-chapters are those that are supported

by the final version of the IM@GINE IT system platform. They are sorted according to

the “environment” in which they are used. The first chapter handles the UC that have

a global character, that is, that are covering more than one test site. The other

chapters describe those UC which are specifically supported in this site. For more

details on the UC please refer to deliverables D1.1 and D1.2.

2.1. Global system use cases

UC No. UC Description Screenshot

1 Register : This UC cover the registration of the user. The User has to fill in his personal data that are necessary to provide him personalized services. The registration does not cover the User Profile.

2 Login: The user logs into the

system by using his Name and Password. He can chose between three different roles: Businessman, Tourist or Commuter.


December 2005 5 PTV


3 Change account details: The user may change his account details such as home address or other personal details such as Login and Password.

4 Un-register: The User may un-

register if he does not want to use the system anymore.

5 Download application: This UC

allows the user to download the IM@GINE IT mobile application from a central server for installation on his mobile device. In future this option could be provided by a telecom operator, depending on the business plan.

6 Bookmark POI or Trip: The

User has the possibility to bookmark certain POI he is especially interested in. The POI are then available to the system without a new search.


December 2005 6 PTV


7 Manage bookmarked POIs: Allows the User to organize and manage bookmarked POI.

8 Add trip to cart: The User has

the possibility to save trips he is using very often. Similar to POI this trips are available without further calculation.

No special HMI

9 Manage Cart: Similar to manage bookmarked POI

See UC 7

10 Store a trip or a journey: See UC8

See UC 6

11 Manage stored trips: See UC 9 See UC 7 13 Administration of the system:

The administrator of the system is allowed to make changes to the system. He may add new software or link additional services (update meta data).

No special HMI

14 Plan a trip: The User may plan a trip with start and destination point. He may chose between several options. He may plan the trip on his home PC or on his mobile device.

15 Give me alternative’s details:

After the User has received a selection of trips, he may chose one of them and ask for additional more detailed information such as more detailed maps.


December 2005 7 PTV


19 Continue trip planning: See UC 15

20 Route information: The User

may request additional information along a certain route, for example POI

21 Destination information: The

User may ask the system about information regarding his destination. This could be detailed maps, POI or transport events.

22 Transport terminal

information: The User may ask about details regarding a certain transport terminal on his trip, such as public transport information.


December 2005 8 PTV


23 Guide me around: User may use his current position as origin. It is retrieved automatically on User request. He may also enter any other location. He will get any detailed information available around his current position, that he may also define as his home area.

24 Select POI & POI information:

The User may request more detailed information on a certain POI. The available information depends on the service.

27 Activate trip: The User may set

a trip to “active” in order to automatically get certain information based on his user profile. The system monitors the trip progress.

28 Plan a trip while on active

(stored) trip: The User may want to plan a new trip or change a trip planning while he is using an active trip.

29 Guide me around while on No special HMI


December 2005 9 PTV


active trip (Where am I): The User gets his current position and information on his surroundings.

30 Route information while on active trip: See UC20

No special HMI

31 Transport terminal information while on active trip: See UC22

NA

35 Get transportation means connection information: The User receives information on public transport connections or information about the next route segment of his trip he is accessing.

NA

36 End active trip: The User may end an active trip.

37 Unexpected Trip Events:

Depending on the service availability, the User may be notified about events referring to his route.

NA

Table 1: Global Use Cases

2.2. Italy

The Use cases that are demonstrated in Italy follow below.

UC No. UC Description

25 Parking availability: Real time parking lot availability are made available. The service covers 14 parking area in the Turin premises.

26 Show me public transport timetables: Real time and static time table of public transport are made available. The service covers more than 3000 PT stops in Turin and surround.

32 Navigate to: external MMS OBN system is used to be guided along a route. The destination and the current position is given from the NDA to the external navigation application. Maps are in tiny SVG format, suitable for mobile devices.


December 2005 10 PTV


33 User gets in and off the vehicle: the user is pedestrian and he is using the PDA 1. the user gets in the car 2. Bluetooth connection between PDA and in car device 3. NDA in the car device understand that the user is changing context of use 4. PDA NDA application stops 5. automatically on the NDA in the car device start a new session (login is transparent to the user) 6. the user can continue to join service from the same session. The same process happens when the user gets off the car and become a pedestrian.

39 Find best fuel station: fuel stations are part of the POI data base for the mapping and routing service. Several information are available: phone number, description, web site and so on.

40 Find best parking: parking areas are part of the POI data base for the mapping and routing service. Several information are available: phone number, description, web site and so on.

Table 2: Italian Use Cases

2.3. Greece

The following UC are restricted to the Greek test site.


12 View Bookings: The user may view the bookings he has done previously, e.g. for a seat in pt or a theatre ticket. NA

16 Ask seat availability: This WS is part of the booking process. When the user requests a booking the system initially makes an availability request. If the request is successful the “book ticket” service is automatically called, otherwise an error message is produced.

17 Book / Buy ticket: This WS allows the user to book flights that are trip segments of a stored trip. After a successful call for seat availability the system automatically requests the booking service for a trip segment and returns the result of the request.

26 Show me public transport timetables: This WS allows the display of time tables for all public transport means departing from and going to the Athens International Airport.

33 User gets in and off the vehicle: If the user gets in a car the map of the current trip is displayed with a respective message. When the user gets out of the car the functionality is returned to normal.

41 Cancel Booking: The User may cancel a previous booking. 42 Car rental: This WS allows the user to search car rental companies that are near

the area and make a reservation request. Table 3: Greek Use Cases



2.4. Germany

The following UC are restricted to the German test site. Car rental agencies and fuel

stations are part of the POI database. In addition, Park&Ride is available as POI in

Germany.


26 Show me public transport timetables: This WS allows the display of public transport time tables. The data base behind it is the same as for the IMR.

33 User gets in and off the vehicle: If the user continues his trip as a pedestrian, the necessary details about his current trip status have to be transferred from the car on-board unit to the mobile device and vice versa.

34 Download Destination to car: A part of a route that has to be driven by car can be downloaded from the mobile device to the on-boar unit of the car. The journey can be now continued by driving with the build-in navigation system of the car.

Table 4: German Use Cases

2.5. Hungary

The Use cases that are demonstrated in Hungary are included in the following table.


26 Show me public transport timetables: The WS calculates the very next start time of the given run from the nearest stop. Works for all public transport vehicles of Budapest and it’s neighborhood cities. The content comes from the local public transport company BKV.

32 Navigate to: route calculation between any number of addresses within Hungary. Time, distance, priority optimization. Car, pedestrian, or public transport (later within Budapest city and it’s neighborhood only).

33 User gets in and off the vehicle: The user assigns a location, where she/he leaves the car, and continues his trip by foot.

39 Find best fuel station: The information about each station contains name, address, phone number and opening period. Can be searched by name, by any data content, within a rectangle, along a route.

40 Find best parking: The information about each parking place contains name and address. Can be searched by name, by any data content, within a rectangle, along a route.

42 Car rental: The information about each car rentals contains name, address, phone number and opening period. Can be searched by name, by any data content, within a rectangle, along a route.

Table 5: Hungarian Use Cases

2.6. Finland

Below, the Use cases that are demonstrated in Finland follow.




12 View Bookings: The user may view the bookings he has done previously, e.g. for a seat in pt or a theatre ticket. NA

18: Reserve hotel: Enables the user to make hotel reservations through the functions of the GoFinland portal.

26 Show me public transport timetables: Shows pt time tables for the whole of Finland based on the database of MTC.

41 Cancel Booking: The User may cancel a previous booking. Table 6: Finish Use Cases



3. Global service architecture

3.1. Project global system architecture

3.1.1. Deployment scheme

The IM@GINE IT global system architecture connects the local system architectures

that are described in the following chapters. The global architecture consists of the

Multi Agent System B2C server (MAS-B2C) and the Internet. The MAS uses Web

services to link the local sites through the Internet, based on the project ontology.

The MAS is hosted on servers from partner 5T. The following figure provides an

overview of the system network.

Figure 1: Deployment scheme

The distributed architecture will have effect on the overall system performance. It is

not necessarily the long distance between the servers in each site that represent the

systems bottleneck, but the networks of the mobile network operators in each

country. GPRS is very slow compared to a normal Internet connection, and although



UMTS is now available in most of the EU countries, the market is still lacking UMTS

enabled phones.

This situation will affect the evaluation of the services by the end users and should be

considered already in advance. As it affects the impression the user gets from the

system, it also affects the business model and the market forecasts that will be

presented in other deliverables at a later stage. However, the project consortium has

no influence on this situation as it relays on devices and networks that are already

available in the market and thus easily accessible to the end user.

3.1.2. Supported positioning technologies

In D1.2 the project analysed different technologies that can be used for positioning of

the user. Far not all of them are in a development status where they can be

integrated into a project like IM@GINE IT without additional financial and work effort.

Thus the consortium decided to concentrate on the most advanced and already

commercially used technologies. The table below provides an overview of the

situation in the different test sites.

Test site Positioning Technology

Greece GPS, Cell-ID

Italy GPS, A-GPS

Germany GPS, (Cell-ID)

Hungary GPS

Finland GPS

Table 7: Supported positioning technologies

Brackets mean that the feature is optional and can be implemented without much

effort. For Greece the provider for the Cell-ID service is VODAFONE (see also

chapter 4.3.8).

3.2. Italian system architecture

The Italian pilot site architecture is composed by the following modules:



1. GIS platform: MMS central GIS platform provides for the following services:

► geo-coding;

► dynamic car and pedestrian routing;

► mapping;

► traffic information;

► POI information.

All the services are exposed as W3C compliant Web Services with an SOAP/XML

interface.

2. 5T web services module: Within the Italian test site a specific web service (to5T WS) is responsible for the provisioning of 5T information about: Public transport

timetable, Turin urban traffic information and parking availability. The service is

exposed as W3C web service with a SOAP interface.

3. Central MAS-B2C server: Central system connecting all modules of the site. It is hosted at 5T servers. Both MMS and 5T web services are provided to the nomad

device applications trough the MAS.

4. Nomad Device Application: NDA represents the core of the device application. It is responsible to manage the agents located on the device, the link with the

HMI and the interaction with external application and micro-services. The Italian

site implemented NDA for the class of devices: mobile phones and smart phones

(MOTOROLA E1000 and MOTOROLA A1000), PDA and the in-car telematic

platform. The following figure shows the automotive architecture:

Figure 2: Italian in-car architecture



With the equipment described above the Italian test site is demonstrating two

different transport modes for the user: driver and pedestrian.

5. External Off board navigation application: MMS OBN application is linked to the mobile phone nomad device application as external application. It offers an off

board navigation service for the car and pedestrian transport modes. The

navigation application guides the user to the selected destination by showing the

user route on a map that can be zoomed. Maps and routes are downloaded from

the MMS navigation server and are updated with the current traffic situation.

The following figure illustrates the physical test site architecture:

Figure 3: Physical Architecture of Italian Site.

3.3. Greek system architecture

The platform of the Greek test site consists of the following hardware equipment:

Type RAM Processor Operating System

Frontplane 1 512GB 1,7GHz Windows 2000

Backplane 1 1GB 2,8GHz Windows 2003 Server

Table 8: H/W equipment of the Greek site



The services of the Greek site run independently from other hardware installations at

TREDIT, but since IM@GINE IT is a research project, the server is not monitored 24

hours per day, 7 days per week.

3.3.1. Functional architecture

The Greek pilot consists of the following modules:

► F.1 Information Module.

► F.2 TouristicInfo Module.

► F.3 Routing Module.

► F.4 GIS Module.

► F.5 DM Module.

Figure 4: Greek pilot modules.

The Info Module is part of the application layer and implements the SOAP/XML Web services in order to handle the flight information requests. It collects the necessary

data from external systems, formulates them properly and sends them to MAS.

The TouristicInfo Module is part of the application layer and implements the SOAP/XML Web services to handle all the tourist information requests. The

respective data is kept in the local DB and in particular it provides timetables for the

public transport means and the functionality for POI search and relative information.

The Routing Module is part of the application layer and implements the SOAP/XML Web services in order to handle properly the requests for routing and provide public

transport routing for travel segments concerning interurban trips in Greek territory.

The GIS Module is part of the application layer and implements the SOAP/XML Web services in order to handle properly the requests for GIS services. It communicates



with the PTV server to pass the requests as well as receive the replies for mapping

and geocoding services for the area of Athens and Thessaloniki.

The DM Module implements the interface of the application to the platform’s local database in order to insert, update, delete and retrieve data.

The Greek pilot implements interfaces with the following “external” systems in order

to provide its service:

► PTV Server.

► INTELLECT Server.

► AIA Server.

► TIETOTALO DMM instance

► Furthermore, a user of the Greek pilot can have access to SABRE HELLAS system through the NDA for flight reservation and car rental.

The Greek site provides the following services to MAS:

► Mapping & geocoding.

► Multi-modal interurban trip planning (car, pedestrian and public transport).

► Urban level car and pedestrian routing for Athens and Thessaloniki.

► Interurban public transport trip planning.

► POI search and selection for Athens and Thessaloniki.

► Urban public transport information for Athens International Airport.

► Dynamic flight information for Athens airport.

The Greek site will demonstrate access to the above-mentioned services through

NDA as well as a research telematic vehicle of CERTH/HIT.

Finally, another service that is provided directly from the mobile device to the user is

the automatic WiFi connection of the mobile device with the ADAMANT server in the

area of the Athens International Airport (AIA). In that case two new services become

available: dynamic navigation of the user in the area of the airport and real-time flight

information.



Figure 5: Functional Architecture of Greek Site

3.3.2. Physical Architecture

The Greek site will consist of the following parts:

► Application Server: The application server will be the basic component of the Greek site. All the necessary functionality will be implemented there, as well as all the required interfaces towards the external service providers and vice versa. Moreover, the interfaces with the local database will exist in order to collect and use any necessary data.

► Database Server: The database server will have the database where all the necessary information will be stored. The database will mostly contain cached data from information requests as well as any other information that will have to be stored locally.

The following figure presents the physical architecture of the Greek site:



Figure 6: Physical Architecture of Greek Site.

3.4. German system architecture

The GIS platform of the German test site (yellow part in figure 7 plus VISUM and

Web Services) consists of the following hardware equipment:


Frontplane 1 1GB 1,5-2GHz Windows 2000 Server

Backplane 1 1GB 1,5-2GHz Windows 2000 Server




Table 9: Hardware German GIS platform

The services of the German site thus run on their own platform independently from

other hardware installations at PTV. As IM@GINE IT is a research project, the

servers are installed in a so called “non-productive” environment. This means that

there is no guarantee for features like 24/7 monitoring, or high performance access.

Starting from the bottom of figure 7 below, the overall system of the German test site

consists of the following components:



HACON IMR: This is a routing server and data base that contains the data of the regional public transport (pt) operator Rhein-Main-Verkehrsverbund (RMV), which is

one of the larges public transport operators in Germany. In addition, it contains the

flight database which is used in the project. The server is calculating the PT routes

(train, tram, bus, flight) and provides it to the PTV Mobility Platform.

The Mobility Platform (MP) is running on project owned servers independently from other installations at PTV. The MP is the business logic of the German test site, i.e. it

coordinates the requests and responses to and from the different connected servers

and links them to the Web Service layer (SOAP XML).

The eServers are the modules connected to the MP which are responsible for the data processing in a certain task, e.g. routing, geo-coding, mapping, etc. The servers

are connected to the content data bases of PTV which contain POI information, traffic information and other geo-related content, such as maps.

The Web Service layer comprises all the different Web services (Traffic Info, Mapping, POI Search, etc.) that are offered through the German test site. They are

the direct link to the Multi Agent System (MAS). Web Services are W3C conform and

based on SOAP/XML.

The VISUM Information Server is the server that is responsible for the calculation of the in-door routing at the Frankfurt International Airport. The service is kept separate

from the MP as it will allow more flexibility for future developments and changes in

the system. The in-door router has its own Web service towards the MAS and is

requested separately by the front end application or an agent of the MAS.

The DC Server and Agent Interface is a server that is located at DC premises in Stuttgart. The server handles all requests and responses that are coming from and to

the on-board unit in the test car and the MAS. The information transferred is mainly

based on the start and destination information, which is then used by the car

navigation (COMAND System from BECKER).

The MAS is the central point for all “remote” modules of the test site system. It links in an intelligent way the backend servers of PTV/HACON with the on-board unit in

the test car of DC and the Nomad Device Application (NDA), which is owned by the end user.



Figure 7: German system architecture

Through the above constellation it can be ensured that the information flow between

the different travel modes the user may be in, kept up-to-date.

3.5. Hungarian system architecture

The system contains two IBM PC compatible machines: the first implements the Web

Service/Internet functions, while the second processes the GIS functions.


Web Server 1GB 2GHz Windows 2003 Server

GIS Server 4GB 2 x 2.6 GHz Windows 2003 Server

Table 10: Hardware of Hungarian WS GIS platform



The Web Server is responsible for communicating with MAS in a standard Soap/XML

manner, while the GIS server will actually perform all MapDrawing/Poi/Routing

services. The GIS server contains the necessary map/car-pedestrian/public transport

/Poi data. The computers operate 24 hours/day during the evaluation process of the

project. Both of these sites were implemented in a Microsoft .Net environment.

3.6. Finnish system architecture

The Finnish site platform will be operated by Tietotalo Infocenter Ltd. The gateway to

Finnish IM@GINE IT system will be the GoFinland portal.

The Finnish site platform will be implemented using the following technologies:

► Platform: Java (J2SE / J2EE)

► Application server: JBoss / Tomcat

► Database: MySQL

► Web Services: Apache Axis

Servers: Linux Intel based

The objective of the Finnish site is to implement, validate and evaluate the service

and technology developed in IM@GINE IT that enables a consumer to receive

location and routing based information about public transport and tourism services.

The Finnish site will utilise for this both the Public Transport Portal of the Ministry of

Transport and Communications and the information distribution channel and

technology applications that Go Finland Oy (GFO) operates to support the Finnish

tourism industry.

The Finnish site implements a platform integrating the following services / content:

► POI search and tourism information using Go Finland and its partners’ data (including for example Finnish Tourist Board).

► Hotel booking.

► Public transport timetable information provided by MTC.

► Public transport routing provided by MTC.

► GIS services (mapping and geocoding and car routing) provided by PTV.



Go Finland offers a connection to tourism information services in Finland. For

example Finnish Tourist Boards national tourism information database will be

accessed through Go Finland.

The Finnish site implements interfaces with the following “external” systems:

► PTV (GIS).

► Go Finland (Tourist information, Hotel reservation).

► Finnish Ministry of Transport and Communications (PT timetables db, PT routing system).

► Finnish Tourist Board (via Go Finland).

A local database will be used to store user profiles and this data will be accessed via

DM. The DMM will act as a gateway to the following services:

► Hotel booking.

► Tourist information.

► PT information.

► User profile management.



4. Interfaces and services in the test sites

4.1. Service interfaces in Germany

The PTV Mobility Platform is built on top of the J2EE framework. Each component is

implemented by a session bean that can either be stateless or statefull, depending

on the service. That session bean can either be accessed from local clients (e.g.

other modules or services) using the RMI protocol, or from applications using Web

Services. Figure 8 gives an overview of the technical communication aspects of

some typical platform components.

Figure 8: Platform technical system architecture (POI Search example)

A web service request calls the SOAP interface of the POISearchService web

service servlet running in the servlet container. The servlet delegates the call to the

POISearchService session bean running in the EJB container using the RMI

interface. The session bean starts an internal server workflow to calculate the desired

result and returns it to the servlet which generates a SOAP answer and returns it to

the client. Java client applications with RMI access to the platform can call the EJB

directly and therefore save the processing time needed by the web service. In fact,

the picture drawn in figure 8 is a simplified model: The structure of a component is

illustrated in the following figure 9:



Figure 9: Inner structure of a component

The component consists of the core implementation that is located in the

Implementation Delegate classes. Those are wrapped by Internal Session Beans

which are responsible for providing the EJB infrastructure for the delegates. Again,

these sessions are wrapped by the so called facade sessions. The facades are

responsible for three tasks: Authorization checking, transaction logging and implicit

parameter conversion. Finally the facades are exposed to the outside either directly

via EJB/RMI remote interfaces, or indirectly through a servlet providing web service

access to the component. Web services in the PTV Mobility Platform are currently

implemented on top of the Jakarta AXIS framework, which has proven to be efficient

and stable.

Other services and their interfaces which are not based on the Mobility Platform (MP)

are described in more detail below, for example the In-Car integration or the Cell-ID

positioning. If a service is not based on the MP, this is explicitly mentioned in the text.

4.1.1. Inter-Modal routing

The inter-modal route service (IMR) allows requesting a route for a start address and

an end address. Optionally, it may be used one or more via-addresses. Alternatively,

coordinates may be used. If addresses are used, they are first geocoded using the

location module. The resulting coordinates are used as input for routing module



which then calculates the shortest, most economic or fastest route. There are also

methods for retrieving the list of all countries passed by the route.

The route may be calculated static or dynamic. In the latter case, traffic jams,

roadworks and historical speed information of road sections is considered by the

routing algorithm. Optionally, POIs located in the corridor of the route may be

calculated. The corridor width and the DistType (air distance, route distance or route

time) are specified in the RouteProperties object. It is also possible to visualize the

route in a map.

The IMR part of the service allows the calculation of routes by using the following

travel modes: Car, Pedestrian, Train and Plane. Ferry ports are automatically

included without any time schedules, as this is part of the car routing algorithm.

The difference between a normal car routing service and an IMR can be found in the

far more complex requirements towards the IMR. The goal is to define different

routes with different interchanges to the public transport services (including airports).

Each route comprises three parts: Private traffic part, public transport part and

pedestrian part. The processing of multiple interchanges requires the capability of the

service to do m:n routings in the public transport information and routing modules

such as HAFAS, as well as in the private traffic routing module (car routing).

Depending on the position of the vehicle and the departure and arrival constellations

respectively, different algorithms for the calculation of the total route become

necessary.

The IMR is primarily dissolving all routing points (start, via, destination) by providing

selection lists if necessary. Routing points are addresses, stops and POI. For this

process the geocoding and POI search service are used. However, for the public

transport stops this is done by the pt modules such as HAFAS from HACON. Car and

pedestrian routing are done by the normal routing engines. The following figure 10 is

an example from the IMR interface. It describes the START element. Within the

PROD (product) element the selection is made regarding the travel mode, that is,

whether the user wants to chose plane, car, train, etc, or a combination of all

possibilities.



Figure 10: START element of the IMR interface

The IMR was implemented in a way that different public transport information servers

can be requested in future. In order to link private traffic and public traffic route

segments dynamically, the different pt servers have to fulfil special criteria:

► Provision of selection lists if no 100% match to an address is possible. The user must be able to find the exact address through different single steps, if necessary.

► Possibility of having a normal connection information (Start – Via – Dest). The following RoutingPoints are possible:

► Stops.

► Addresses.

► POI (internal matching to addresses).

For the different PT servers this means that they have to be able to process

information, e.g.:



► Stops such as „Frankfurt, Main Train Station“.

► Location points (x,y).

► M:n routing must be possible. The pt servers must accept several stops or location points as Start or Destination Information. It must be also possible to include a time difference for each stop or location point in order to be able to calculate the spatial distances from a certain point to the next station or location point.

► Each pt server must include an external list with all possible stops in combination with their coordinates or access points (with coordinates) in order to enable the proximity search.

Example caller method: getMap (AddressList stations, int maxAddresses, RouteProperties rp, POIViewSet[] s, ImageProperties p, String geoDataSource,

String targetMapName): AddressRouteMapView

4.1.2. Mapping and POI search

The Mapping Service allows to request a map e.g. for an address or coordinate and

a width and height. If an address is used, it is first geo-coded using the location

module. The resulting coordinate is used as centre point for the map which is then

generated by the mapping module. Optionally, additional information like POIs

(including traffic information) may be retrieved using the POI Search Service and

displayed in the map.

Once retrieved a map, it is possible to navigate in the map. Functionalities like

zooming in/out, moving or scaling the map are available. It is also possible to

navigate in the map history to get a previously retrieved map out of the map cache

(current, first, last, previous or next). The resulting maps may be named for later

referencing. Using map names (e.g. “Overview map” or “Detail map”), multiple

navigation histories are possible within one session.

The POI Search Service realizes the nearest search request based on direct

distances, route distance or route time. For some geographical search criteria (e.g.

postal address and search distance) a proximity search with one or more POI

categories may be performed.

The first step is usually to geo-code the postal address with a location module. If

coordinates are available, this step is not necessary. Then, the POI search is



performed for the desired categories using the POI Search Service. The resulting

POIs are optionally displayed in a map. For route or time based proximity search,

different speed profiles like slow car, fast car or pedestrian are available.

Figure 11: Inner structure of a component

Example caller method: getMap (Address a, double width, double height, int maxAddresses, POIViewSet[] poiViewSets, ImageProperties p, String

geoDataSource, String targetMapName): AddressMapView

4.1.3. Geocoding

The Location Service is a central component used by a lot of applications. It covers

geocoding and reverse geocoding functionality using the geo-coding engine. In case

of geocoding, it calculates the best matching coordinates for a given address search

criteria which may be then used for mapping, routing or other services. The reverse

geo-code function takes a coordinate and calculates a list of best matching

addresses.

Geocoding may be done for one single address or, in batch mode, for a whole

address list. The batch mode is also available for reverse geocoding (for a coordinate

list).

Example caller method: locate (Address a, LocateProperties p, String geoDataSource): AddressList



4.1.4. Traffic information

The Traffic Information Service realizes the search for traffic messages based on

region, street name or bounding box. Traffic messages are treated as line-based

POIs. The functionalities are similar to the POI Search Service. This includes the

usage of the same transfer objects. The traffic messages are stored in POI layers

with a fixed format defined by PTV. This allows several convenience methods for

easy access to traffic messages.

First, a list of regions or actually concerned road names can be retrieved. Then, the

traffic POI search is performed for the desired traffic provider(s) using the POI search

module. The resulting POIs are optionally displayed in a map with the help of the

mapping service.

The bounding box based search methods consider the bounding box of the traffic

message geometries, not the geometries themselves. Messages with no geo-

reference can be retrieved using the method “getGeneralTrafficInfos”.

Besides the standard POIView attributes the traffic format includes the following

additional values (contained in the attribute “values” of the resulting POIViews):

► ID: Unique message id.

► INFO: Full message text.

► STATE: Name of state (Germany: Bundesland).

► CATEGORY: PTV event code

► DELAY: Predicted delays [min].

► FIRSTENTRYTIME: First appearence of incident.

► UPDATEENTRYTIME: Last effective update of incident.

► COUNTRYCODE: ISO 3166 code for Country (Germany: DE).

► STATECODE: State Abreviation (Germany: Bundesland, z.B.: BW, HH).

► ROAD: Roadnr and/of streetname (language of the country).

► ROADCLASS: 1=Motorway, 2=interregional, 3=regional TMC-located, 4=regional not TMC-located, 5=other, 9=unknown.

► COMPASS: Startpoint endpoint: N, E, S, W, NE, SE, SW, NW.

► LENGTHEFFECTED: Explicite length [m] of traffic congestion.



► EXTENSIONTENDENCY: Tendency [%] of LenghtAffected or Delay; 100=unchanged, 150=increasing, 50=decreasing, -1=unknown.

► LASTEXTENSIONCHANGETIME: Last effective update of LengthAffected or Delay.

► AVERAGESPEED: Speed average [km/h]; ffu.

► STARTTIME: Effective start time of incident. Dynamic message: First message time.

► ENDTIME: Effective end time of incident. Dynamic message: computed expire date.

► LANGUAGE: Message language, ISO 639-1 code ; de=german, en=english.

Example caller method: getRegions(String regionSource, String language): POIViewSet

4.1.5. In-Door routing Web service

For the implementation of the in-door routing Web service it was decided to use the

.NET framework. The intention is that the Web service is requested through the Multi

Agent System (MAS) in the same way as it is done for other project Web services.

The request should contain the start and destination information, and the response

will provide the length of the route in meter and an URL from which the Nomad

Device Application (NDA) can retrieve the in-door map. The necessary components

of the service are schematically described in the following figure 12.

Figure 12: Logical structure of the in-door service



The front-end is encapsulating the users request containing start, destination and

travel mode, into a request object and sends this object through the Internet to the

routing service component. The main task of the Web service is the triggering of a

VISUM instance which is than doing the routing and generating the related in-door

maps. Together with the Web service component this instance represents the main

Web server. The routing result is then provided though a response object back to the

front-end. The front-end application is now free to display the results in a user friendly

way, or to further process the results for other tasks.

4.1.5.1. Web Service Interface

The Web service interface provides the method with which the frontend is able to

transfer the routing parameters and start the routing itself. In the response the front-

end receives the routing results.

Thus, the Web service offers only one method „CalcRoute“ which includes as a

parameter an object called “RoutingPara” and returns a result object called

“RoutingResult”. The parameters contain the ID’s of the start and end points and an

optional travel mode (C1, C2, S1, S2). For example, C1 would be very comfort and

S1 very sportive. The result contains the length of the route, a string that contains the

URL to retrieve the map from, and an error code including the error message if the

service didn’t work properly. The latter may be the case if the routing network does

not “know” the start or end point, or if an unknown travel mode was chosen.

4.1.5.2. VISUM Interface

With the help of the entry parameters the routing service is able to start the routing

process in VISUM through COM. As a preliminary result there is just a route list

available that matches the calculated route. The routing service is then splitting the

route into a sequence of clips in order to be able to provide usable map formats. The

maps them self are also created by VISUM through COM, and the resulting JPEG

files are placed in a public folder of a Web server. The URL to these images is

generated in a way that allows the front-end to retrieve and process the maps in the

right order. After approximately one hour the images will be deleted automatically

from this folder.



As this service is a first prototype, many things may and will be improved during the

testing of the services. VISUM allows changing graphical parameters in order to

adjust the layout of the maps on a different way if necessary. Additional information

may be included in the maps, such as information on the building level the user is

currently in, walking directions or additional POI.

The front-end should take care about the translation between the node IDs and the

names in a user readable format. Thus, if the user enters his starting point as “Long

Distance Train Station” the front-end application should translate this into the

ID11001 to be included into the request to the Web service. In the example below a

route is calculated in the C1 mode from the starting point with the ID 11102 to the

destination point with the ID 22142. The service provides the length of the route

(230m) and the following maps:

Figure 13: Example result of the in-door routing

Examples of IDs:

Start:

► 11001 (Long Distance Train Station)

► 99019 (Parking1)

► 99016 (Parking2)

Destination:

► 22168 (Terminal 1, Gate A42)

► 22163 (Gate A36)

► 22157 (Gate A24)

► 22144 (Gate A15)

► 22405 (Gate A5)



4.1.6. In-Car integration

The COMAND Cockpit Management and Data System combines the control and

display functions for the various audio, telematics and telecommunications

components. COMAND is an interface that allows different functions to be operated

via a LCD colour screen. Depending on the car’s specification, it can be used to

control the navigation system, audio and video devices and the in-car telephone.

Information from the Internet can be accessed using a built-in WAP browser. The

COMAND is an optional feature for Mercedes-Benz S-, E-, C-, and M-Class cars

since years.

Figure 14: Architecture of DC car

The COMAND is used within the project as another end-user interface as an addition

to a PDA for the Use Cases #33 “User gets in and off the Vehicle” and #34

“Download Destination to Car”. For these Use Cases the in-car COMAND APS

navigation unit is used to continue driving a part of a route by car.

To integrate external services, the COMAND system includes a WAP 1.* browser.

Besides WAP pages the browser understands a special MIME type message called

CSI (Common Service Interface) to implement location-based services (LBS), traffic

data, and fleet management. All of these services are server-based and are initiated

by the COMAND client.



The DC server (figure 14) contains the logic to handle all WAP requests by the

COMAND end-user and translates them to web service calls to the MAS:

► The initial user action is to log into the IM@GINE IT system by the COMAND giving a user name and password. Using these data the server logic tries to log into the MAS using a web service call. (A user can choose to avoid this action, if the user name and password is saved on the server and locked to the car resp. the COMAND identified by the COMAND device id.)

► Starting a part of a trip by car using the COMAND navigation unit, the user informs the server that he is in the car and that he wants to use the COMAND navigation system. The server will then inform the MAS and asks for the user’s next car destination using web service calls to the MAS. The returned destination will be downloaded to the COMAND navigation unit by the server and the navigation unit will be started using CSI messages.

► During the trip the COMAND navigation unit will route and navigate the user independent from any server.

► At the trip destination the user informs the server that he will now leave the car and that he wants to use a PDA for the remaining parts of the trip. The server will inform the MAS.

Example web service calls to the MAS: getInOrOutOfTheCar(String username, String password, boolean getIn): Boolean, getNextUserCarDestination(String

username, String password): Coordinates

4.2. Service interfaces in Italy

4.2.1. MMS web services interfaces

The Mizar Mediaservice Map-and-Go Web Mapping system is the platform used for

cartographic applications. It is a web oriented system based on industrial standards

and provides building blocks that can be easily integrated in external systems. The

platform offers a complete control over different geographic layouts and formats.

The Map and Go GIS platform is currently used for all the web based Mizar

Mediaservice products. The following figure gives an overview over functional and

connection aspects of the system.



Figure 15 MMS GIS platform functional architecture

MMS services are provided with a SOAP interface to external applications. The

following sections show examples of the web services interfaces in terms of XML

SOAP request and response messages.

4.2.1.1. Geo-coding

The geo-coding service provides the best coordinates, with door to door precision,

that match with a textual address to search. Also the reverse geo-coding service is

available, giving a couple of coordinates the best matching address is returned. Data

is taken from the TeleAtlas cartography database.



Figure 16 Geo-coding SOAP request example

Figure 17 Geo-coding SOAP response example

4.2.1.2. Routing

The routing service provides the best door to door route from an origin to a

destination place. The user can choose between many routing calculation options



like: on foot, by car, the shortest, the fastest and the cheapest one. Routes are

calculated with an advanced routing engine, MMS proprietary, that considers real

time traffic data integrated into its algorithms.

Figure 18 Routing SOAP request example

4.2.1.3. Mapping

Maps are updated to the latest TeleAtlas MultiNet cartography data and are

ultimately generated by means of ESRI ArcIMS. The user can request a map: giving

the map center and radius; specifying the bounding box in terms of coordinates; or

giving a list of icons or routes he/she wants to see on the map. The mapping service

can be integrated with the routing and POI services to compose detailed and

thematic maps. Two output raster image formats are available (PNG, JPEG).



Figure 19 Mapping SOAP request example

Figure 20 Mapping SOAP response example

4.2.1.4. Traffic Information

The Traffic Information Service provides information about traffic events that affect

main roads of several European countries. Traffic event search can be restricted to a

circular area, a bounding box or to a TMC street (encoded in the national RDS-TMC

table code). Traffic information include details such as: date of event, source of



information, direction, involved road stretch, description of the event. Mizar

Mediaservice supplies information about the real time situation of road and highway

viability situation, travel time, position and length of queues, accident, road works and

weather information.

Figure 21 Traffic information SOAP request example



Figure 22 Traffic information SOAP response example

4.2.1.5. POI search

Point of interest are collected from the TeleAtlas database and from the Mizar

Mediaservice internal database. Two-level categorisation is available. The POI

proximity search can be restricted to a circular area or to a bounding box.

Figure 23 POI search SOAP request example



Figure 24 poi search SOAP response example

4.2.1.6. Navigation service

The navigation application is an external application integrated into the IM@GINE IT

smart phone application. It is a Java MIDP compliant application implementing an off-

board navigation. The following figure gives an overview over the OBN architecture.



Figure 25: MMS Off Board Navigation Architecture

Maps and routes are downloaded dynamically from the MizNav server and are

updated to the current traffic situation and to the latest TeleAtlas cartography version.

Maps are in SVG Tiny format, a W3C Standard for 2D vector graphics especially

suited for mobile application with limited processing and memory capabilities. The

client application is a JAR library and has the following interface with the IM@GINE

IT NDA application:

1. The main class used for the navigation is the MMSCanvas class which is a

javax.microedition.lcdui.Canvas subclass.

MMSCanvas navigator = new MMSCanvas(yourMIDlet, parentDisplay);

2. The current position is set with this method:

navigator.setPosition(GPSPosition currentposition);



3. The destination address is set with this method

navigator.setDestination(new Coordinates(destinationLongitude,

destinationLatitude), destinationDescription);

4.2.2. to5T Web Service

“to5T web service” represents the interface towards IM@GINE IT system and 5T

services. The web service is integrated in the IM@GINE IT MAS, TomCat 5.0

application server. The web server has been developed in Java upon the AXIS

framework and makes possible the access to 5T database through the driver of

Microsoft SQL server.

Figure 26: to5T WS integration in MAS

The web service provides 4 methods for the access to 5T information, which are:

► to5t:getPTTimetable: Returns arrival time for a requested stop.

► to5t:getTrafficInfo: Get traffic info.

► to5t:getParkInfo: Get real-time data on car parks.

5T Services SOAP operation name Dir Name Type Description

to5t:getPTTimetable Returns arrival time for a requested stop

IN time xsd:dateTime

IN stopCode xsd:string Unique stop code (primary key)

IN stopName xsd:string Stop name/description

OUT timetable to5t:PTTimetable



5T Services SOAP operation name Dir Name Type Description to5t:getTrafficInfo Get traffic info

OUT info to5t:TrafficInfo[] List of information found

to5t:getParkInfo Get real-time data on car parks

IN parkName xsd:string[] IDs or name of parking

OUT parkData to5t:ParkInfo[] List of car parks found

Table 11: Details about 5T services

Figure 27: 5T Park Info service Sample



Figure 28: 5T Traffic Info service Sample

Figure 29: 5T PT Timetable service Sample



4.3. Service interfaces in Greece

The services provided by the Greek pilot are built using the .NET framework and they

are divided into 5 main categories:

► Routing. It provides the functionality for creating inter-modal routes.

► GIS Services. It included methods for displaying maps and providing geo-coding functionality.

► POI Services. It includes methods for searching and retrieving information about POI.

► Flight information. It includes methods for requesting information about flights in the Athens International Airport and retrieving timetables of public transport means in the Athens International Airport.

► Booking. It includes methods for performing booking requests for flights. The first four services can be accessed from any application using Web Services, while the booking services are included in the NDA.

Each service can be accessed from any application using Web Services.

4.3.1. Inter-Modal routing

The inter-modal route service allows requesting a route for a start and an end

address. Alternatively, coordinates may be used. If addresses are used, they are first

geocoded using the location module. The resulting coordinates are used as input for

routing module which then calculates the shortest, most economic or fastest route.

Optionally, POI located in the corridor of the route may be calculated. It is also

possible to visualize the route in a map using the mapping service.

The service allows the calculation of routes by using the following travel modes: Car,

Pedestrian, Train and Plane.

Each route comprises three parts: First mile car/pedestrian part, public transport part

and last mile car/pedestrian part. The service performs a proximity search in order to

find the nearest terminal(s) of the starting and the ending point and then performs a

car/pedestrian route from the starting point to the starting terminal(s) and from the

ending terminal(s) to the ending point and a public transport routing from the starting

terminal to the ending terminal. Upon the calculation of the above routes it performs

an M:N:Y combination routings, where M are the possible solutions for the first mile,



N the possible solutions for the public transport part and Y the possible solutions for

the last mile.

The Routing service is provided through the respective PTV engine for the

car/pedestrian route and the INTELLECT server for the Public Transport route.

Example caller method: createRoute(Coordinate origin, Coordinate destination, string[] usingTransportType, string usingOptimization, DateTime start, DateTime

finish, string language, int maximumReturnedRoutes) : Route[]

4.3.2. Mapping

The Mapping Service allows the user to request a map e.g. for an address or

coordinate and a width and height. The address or coordinate is used as the centre

point of the map generated by the respective module. Optionally, information such as

routes that are produced by the routing module may be displayed in the map. Once

retrieved a map, it is possible to navigate in that map. Functionalities like zoom

in/out, move or scale are available.

The Mapping service is provided through the respective PTV engine.

Example caller method: getMap (Address a, double width, double height, int maxAddresses, POIViewSet[] poiViewSets, ImageProperties p, String

geoDataSource, String targetMapName): AddressMapView

4.3.3. Geocoding

The Location Service is used by other applications of the Greek pilot, such as

mapping or routing. It provides geocoding and reverse geocoding functionality using

a geo-coding engine. In case of geocoding, it calculates the best matching

coordinates for a given address search criteria. The reverse geo-code function takes

a coordinate and calculates a list of best matching addresses.

The Geocoding service is provided through the respective PTV engine.

Example caller method: locate (Address a, LocateProperties p, String geoDataSource): AddressList



4.3.4. POI services

The POI services implement the functionality for searching POI in an area and

retrieving detailed information about a selected POI. The search for POI is performed

based on coordinates. Alternatively an address can be provided, which will be

geocoded. The service performs a search to find POI that are inside a search zone -

measured in distance – of the provided coordinates and returns a list of the POI that

match the criteria.

The service provides also the possibility for the user to request detailed information

for a specific POI. The POI can either be selected from the list, e.g. the resulting list

from the “search POI” functionality, or can be a single POI, e.g. a bookmarked POI.

The detailed information contains information such as the address and the contact

details of the POI, a description etc.

Example caller method: searchPOI(POISearchInfo psi): POI[] getPOI(string poiId): POI

4.3.5. Public transport timetables

The public transport timetables service provides the possibility to retrieve the

timetables of the public transport means that either go to or depart from the Athens

International Airport. The timetables are static data located in the database of the

pilot and can be retrieved for a specific mode and the result is a list of the public

transport lines that match the search criteria.

The data is retrieved from the local DB of the Greek pilot.

Example caller method: GetPTTimeTable(DateTime Date, string Line, Coordinate Location, string station, string Company, string usingTransportType):

PublicTransportTimetable

4.3.6. Flight information

The flight information service provides the possibility to access updated information

regarding the status of arriving and departing flight of the Athens International Airport



for a specific date. The result is the list of flights for that date with the latest

information regarding the flight status and estimated times of arrival/departure.

The data is collected directly from the AIA server every 5 minutes.

Example caller method: GetDynamicFlightInfo(DateTime date) : PTTimetable[]

Documents

Integrated Service Description - TRIMIS...2013/01/28 · INFORMATION SOCIETY TECHNOLOGIES (IST) PROGRAMME IM@GINE IT IST-508008 Integrated Service Description Deliverable No. (use