Brussels, 22 nd of May 2007 1 Freeflow tolling system Including passenger monitor system GJU Contract No.: GJU/06/2423/CTR/LMHC-TTCS

1

Brussels, 22nd of May 2007

Freeflow tolling systemIncluding passenger

monitor system

GJU Contract No.: GJU/06/2423/CTR/LMHC-TTCS

2


Freeflow tolling system with protection ofpersonal data – including passenger monitoring

system

The consortium is composed of four members:

• Logina d.o.o. is a SME from Slovenia that is the coordinator of the project. It is a producer of vehicle tracking systems and also has a control centre for controlling the network of Slovene Health terminals.

• Moretti S.r.l. is a family owned SME from Italy. It works in the field of automation of public and private transit companies. It also supplies and installs AVM (Automatic Vehicles Monitoring).

• Hamburg Consult GmbH is a SME from Germany. The company is active in the field of traffic management systems, which improve profitability and appeal of public transport.

• The Traffic Technical Institute is part of the University of Ljubljana’s Faculty of Civil and Geodetic Engineering. They perform transportation planning, traffic control, safety and ecology, roadway design and geographic information systems.

3


Agenda

1. Description of the Project & Summary of Objectives2. Presentation of the planned programme and the work

undertaken3. Results of the design process and description of the

system4. Tests and results5. Milestones6. Next steps and commercialization7. Main positive aspects8. Conclusions

4


1.1 Strategic background of the project

Ideas for the project:

• The public’s ever increasing awareness that toll should be charged fairly,

• Work on The Feasibility study on initiation of free flow electronic toll collection system in the Republic of Slovenia,

• Reducing costs of toll collection,

• Paying toll without stopping.

Major challenges:

• Ensuring protection of personal data,

• Fraud resistance,

• Electronic toll payment.

Galileo:

• Improved reliability and better accuracy only with GPS,

• Use of an European system.

5


1.2 Description of the project

• Create a freeflow toll charging system using EGNOS-enabled GNSS/GSM

• Charge buses according to the number of passengers

• Making a system that can make an analysis of road load

• Making a system that can make an analysis of public transport

6


1.3 Objectives

The main objectives of the project were:

• A prototype Control centre.

• Prototype Toll meter or On board unit (OBU).

• A system that can charge toll in relation to the number of passengers on the bus.

• Electronic map of virtual toll stations.

• Protected communication between the control centre and the OBU.

The end product is a system that allows anonymous toll collection

without the drivers even having to stop. This should prevent most

of the major traffic jams which occur when a larger mass of

people is on the move, which happens before and after every

major holiday, during the summer months, when major events

are held,....

7


1.4 System Overview

Control centre OBU

GPS GALILEO

GSM SIM

GSM GPRS

OBU procesorOBU SIM

LCD monitor

IP Sec

passenger counter

User account

8


1.5 Project schedule

Detailed description in deliverable D7.1

9


1.6 Project Budget


Effort (Hours)

Cost €

Planed 11.348 299.949

Actual 10.834 289.025

10


Agenda

1. Description of the Project & Summary of Objectives2. Presentation of planned programme and the work

undertaken3. Results of the design process and description system4. Tests and results5. Milestones6. Next steps and commercialization7. Main positive aspects8. Conclusions

11


2.1 Toll system basics

• EXISTING TOLL SYSTEM

– Closed toll system• paid by the distance traveled• both entry and exit toll stations

– Open toll system• toll stations located on specific freeway cross-sections• paid by the price of cross-section passed through,

independently of either entry or exit point

12


2.2 Problem areas

• Neighbouring traffic areas – EGNOS-enabled GNSS accuracy and logic related problems

– other state roads,– municipal roads,– non-categorized roads,– forestry roads,– field roads,– parking spaces,– other traffic areas.

• Impacts of engineering and other structures – EGNOS-enabled GNSS reliability related problems

– overpass,– underpass,– tunnel,– cut,– tall buildings.

13


2.3 Guidelines for algorithm development

• Respond correctly to technical limitations in a real environment (e.g. blackout of the GPRS and/or the EGNOS-enabled GNSS signal).

• Operate properly in the process of an increase of the number of users and toll stations.

• Minimize system requirements.

• Minimize communicational requirements.

• Protect privacy.

• Minimize the human factor.

14


2.4 Basic algorithm

• Has to enable the collection of the position of the vehicle.

• If the vehicle crosses any of the virtual toll stations in the electronic map, then the Control centre has to be notified to charge toll.

15


2.5 Terminology

• Virtual Toll Station

• Is composed of one or several quadrilateral areas.• In this manner we produce larger adaptability in a real

environment.

16


2.6 Terminology

• Electronic mapIt is the list of virtual toll stations that the OBU asks for.The Electronic map is the key element of the system.

Limitations when designing the electronic map:

• Memory capacity of the toll-meter (OBU)The device is able to store only a part of the entire map.

• Communication bandwidth between the OBU and the Control centreThere should be as little communication as possible.

17


2.7 The “Quadtree“ model

• The idea behind quadtree is dynamic map partitioning based on toll station distribution.

• A Cell is a rectangle with precisely defined geometrical position.

The sides of the cells are parallel with meridians and parallels of latitude.

• The cell contains all the toll stations which (partially) lie inside the area, covered by the cell.

• The Electronic map is a tree structure with individual vertices of cells.


18


2.8 Quadtree electronic map

The electronic map is built according to the following principles:• Electronic map can cover small region, whole EU or even whole world

• The entire electronic map must be covered by a starting-point cell, which represents the root of the tree structure.

• A maximum number of toll stations, which could be contained by individual cell, are defined. Otherwise the cell needs to be subdivided in four equal quadrants.

• Newly emerged cells represent the leaves of the vertex of the subdivided cell.

• The subdividing is recursively repeated until all the leaves contain the allowed number of stations.

Quadtree structure is very suitable for roaming


19


2.9 The “Quadtree”

R1.1

R1.3.1

R1.2

R1.4

R1.3.4R1.3.3

R1.3.2

R0


20


Agenda


undertaken3. Results of the design process and description


21


3.1 System Overview

Control centre OBU

GPS GALILEO

GSM SIM

GSM GPRS

OBU procesorOBU SIM

LCD monitor

IP Sec

passenger counter

User account

22


3.2 Sample of map structure

23


3.3 Current cell structure

24


Cell zero

• OBU position is inside cell zero

• Is cell zero leaf of structure?

Current OBU structure

25


Returned cell zero structure from Control Center

• OBU position is inside cell 3

• Is cell 3 leaf of the structure?


26


Returned cell 3 structure from Control Center

• OBU position is inside cell 3_4

• Is cell 3_4 leaf of the structure?

• Control Center sends Stations data


27


Leaf cell needs to be filled with stations data


28


3.4 OBU request to CC

29


3.5 CC reply to OBU

30


OBU is collecting and processing coordinates from EGNOS-enabled GNSS

3.6 Vehicle traveling the road

31


OBU is collecting and processing coordinates from EGNOS-enabled GNSS

Vehicle traveling the road

32


Collected coordinate is inside station – crossing of station is detected

Vehicle crosses station

33


3.7 OBU request to CC

34


3.8 CC reply to OBU

35


Three more crossings are detected

3.9 Crossed stations

36


OBU

37


3.11 OBU - block diagram

Detailed description in deliverables D2.2 and D4.1

38


3.12 OBU - timing diagram

39


OBU software

40


3.13 OBU program modules

OBU Manager

- path trace

- electronic map (part)

GPRS Manager

Encrypted communication between OBU and Control Centre

Demand cell updates

Data updates

GPS Manager

Vehicle position

Fills path trace

Check path trace against electronic map IRMA

Smart Card manager

FTP client

LCD manager

User interface

Passenger counter

User account id, keys


41


3.14 Software platform

Operating system: Microsoft Windows CE 5.0Programming language: C++Development tool: Microsoft eMbedded Visual C++ 4.0 with

CM_X255_INET_SDKExternal libraries used: zlib 1.1.4, rsaeuro 1.04

OBU main program has been developed as multithreaded Windows application:

• Main program thread (OBUMainThread)

• Thread for receiving GPS data and storing them into trace buffer (GPSThread)

• Thread for checking smart card reader status and reading data from inserted card (SmartCardThread)

• Thread for data communication via GPRS modem (GPRSThread)

• Thread for receiving passenger counter from IRMA device (IRMAThread)

42


• Communication:

• Modified FTP.• Magic number – Session ID stored on Smart Card.• Encryption (public and private keys).• Commands in queue.

• Cross calculation:

• Get location from GALILEO/GPS module.• Confirm cell or download new cell.• Check location against cell data.• If location is inside any toll-station:

Generate crossed station command.Put generated command in queue.

3.15 OBU software


43


3.16 IRMA - Infra Red Motion Analyser


44


Control Center

45


3.17 Purpose of Control Center

• Processing OBU requests – communication, download of maps (99% of the time)

• Configuring maps

• Configuring cells.

• Setting prices.

• Managing accounts (creating, deleting, setting conto)

• Planning and managing bus routes

46


3.18 Control Center schematics

Detailed description in deliverables D2.1, D3.3, D3.5 and D4.2

47


3.19 Control centre database

All data are stored in the database LMHC-TTCS.

Main tables:

• Stations,• Areas,• Prices,• Accounts.

Auxiliary tables:

• Crossings,• Times,• Vehicle Categories,• Vehicles – Categories link table,• Bus lines,• Bus lines – Stations link table,• Cells,• Cells Coordinates,• Commands.

48


3.20 Communication with OBU

Detailed description in deliverables D3.1, D3.3 and D4.2

49


3.21 Map management

• Using GIS ArcView software

• Data layers:– Aerial photographs, scale 1:5.000

(source: Geodetic and Survey Authority, precision ± 3m)

– State road network layer (precision ±3m) Measurement using GPS (global positioning system)

3D Three-dimensional, transformed into 2D two-dimensional shape

Aerial photographs Projections State road network layer is updated annually


50


3.22 Map management

• New station is defined

• New area of station is defined using four coordinates

• Optionally new areas are added to station

• Price of station is defined

• Deleting station


• Deleting area

• Checking differences between temporary map that we modify and map that OBUs are using

• Station is added to database

• Cell structure is callculated

• Data can be used by OBU

51


3.23 Account management

• New user is given an account

• Account OBU number is defined

• Account balance is defined and managed

• Account can be annulled


52


• On Board Unit records all necessary data. • Recorded data will be saved in the database of

the CC Base.

• Database will be transferred to the multi-dimensional database-driven OLAP-Cube.

• Report builder is directly based on the OLAP-Cube and offers fixed statistical evaluations.

3.24 Passenger statistics


53


• Reports are based on the OLAP-Cube

• They are generated:

– From the administrator by programming it with multi-dimensional queries and xml

– By the End-User over the Report builder

• Reports can make use of drill-Down, drill-Up and chart diagrams, so that the user can create subsets (e. g. in a special time, for a special bus line)

3.25 Reports


54


• The Report builder:

– provides solutions for data visualization,– has a defined interface

to the OLAP-Cube,– allows the user to create

own statistics, ad-hoc(tables, matrix, graphical statistics),

– generates the statistics in short time and in an easy way.

Reports


55


• For managing reports in a strict way Microsoft provides a web-based report content management system.

• A Web server stores all hand-made or Report-builder generated reports, like distance driven per vehicle, distance driven per vehicle bar chart etc.

Reports


56


Agenda


undertaken3. Results of the design process and description of system4. Tests and results5. Milestones6. Next steps and commercialization7. Main positive aspects8. Conclusion

57


4.1 Goals of project

• Build and code an OBU prototype

• Design and code Control Center prototype

• Demonstration of the system

58


4.2 Test process

• OBU power-up and communication with Control Center

• Control Center functions• map creation• account management• charging

• System integration with Control Center

• Field testing

59


4.3 Observations and data gathered

• Power Supply conditioning (spikes from engine altenator)

• Problems with service port of the OBU

• Various bugs logged and fixed

• Double charging bug detected and fixed

60


4.4 Laboratory Tests

• Communication between the OBU and the Control centre.

• Simulation of driving using recorded NMEA data.

• Critical for analyzing bugs.

61


4.5 Real world environment tests

The main environment tests were:

• Size of a toll-station.

• Vehicle speed limitations.

• Quality of reception of the EGNOS-enabled GNSS signal.

• Influence of the GPRS signal accuracy.

• Passenger counting

• Comparison to existing Electronic Vehicle Book system

Detailed description in deliverablesD5.1 appendix Testing report, D5.2, D5.3

62


4.6 Size a of station 1/5

station name LENGTH WIDTH*

Test1_01 100 -1

Test1_02 100 1

Test1_03 100 3

Test1_04 100 5

Test1_05 100 8

Test1_11 70 5

Test1_12 90 5

Test1_13 110 5

Test1_14 130 5

Test1_15 150 5

Test1_16 180 5

*Width is the distance (in meters) that the toll station covers, measured from the roadside outwards.

Detailed description in deliverable D5.1 appendix Testing report

63


Size a of station 2/5

Direction A Direction Biteration Test1_01 Test1_02 Test1_03 Test1_01 Test1_02 Test1_03

1 /

2 /

3 / / /

4 /

5

6

7 / /

8 / /

9 / / /

10 /

11 /

12 / / /

13 / / /

14

15 / /

16 /

/

Legend: cross detectedcross not detected

64


Size a of station 3/5

Direction A Direction Biteration Test1_14 Test1_15 Test1_14 Test1_15

1 / /

2 / /

3 / /

4 / /

5

6 /

7 /

8 / /

9 / /

10 / /

11 / / /

12 /

13

14 /

15

16 / /

65


Size of a station verification 4/5

station name LENGTH WIDTH*

Test1_21 70 10

Test1_22 70 10

Test1_23 70 10

Test1_24 70 10

Test1_25 70 10

Test1_26 70 10

Test1_27 70 10

Test1_28 70 10

Test1_29 70 10

Test1_30 70 10

Test1_31 70 10

*Width is the distance (in meters) that the toll station covers,measured from the roadside outwards.


66


Size of a station verification 5/5

Direction AIteration 21 22 23 24 25 26 27 28 29 30 31

1

2 /

3 /

4

5

6 /

7

8

9

10

11

12

13

14

15

16 /

17

18

/

Legend: cross detectedcross not detected

Direction B21 22 23 24 25 26 27 28 29 30 31

/

67


4.7 Summary of testing

• Width of a station must reach 10m outwards roadside (empirically)

• Length of a station must be 70m for speeds up to 250 km/h (calculated).

• 98.9% hit rate using existing EGNOS-enabled GNSS (we expect better results when using GALILEO).


68


4.8 Roadways in close proximity test

• Distance of station from road in close proximity must be at least 10m. With Galileo we expect to reduce distance needed.


69


4.9 Map loading test

The loading tests were made of:

• Detection of cell.

• Loading cell data.

• Detection of cell border crossing.

• Adding a station to a cell.

• Removing a station from a cell.

• Adding stations to a cell – split cell.

• Removing stations from a cell – merge cells.


70


4.10 Toll collection test

Toll collection tests included:

• Charging accordingly to vehicle category.

• System charges accordingly to time of driving.

• Number of passengers on bus stations received.

• Loss of GPRS signal does not affect fair charging.

• Malfunction of GPRS modem does not affect fair charging.

• Buffer size for trace.


71


4.11 Test conclusions

• Size of a station depends on accuracy of GNSS signal.

• Size of a station depends on resolution of map data.

• Better results expected when using GALILEO.

• novadays limits for station:• 20m wider than road width,• 70m long,• two stations at least 10m apart from each other.

• Passenger counter works satisfactory.


72


4.12 Test problems

• System communication capacity could not be stressed.

• System overload could not be tested.

• GPRS signal was too strong to test GPRS antenna malfunction.

• We could not test the effect of different weather conditions on the EGNOS-enabled GNSS signal.

• Double charging problem (parking inside toll-station area).

• Double charging bug discovered and fixed (double transactions).

• We state the Magic Number (dynamic password) problems because of incorrect transfers (problem fixed).

• The OBUs have had start up problems because of the service port.

• It loses the GNSS signal in some cases.

73


Agenda


undertaken3. Results of the design process and description of system4. Tests and results5. Milestones6. Next steps and commercialization7. Main positive aspects8. Conclusion

74


5.1 Project schedule


75


5.2 Key Milestones Achieved -1

• 10th - 20th April 2006- Selection of systematic platforms for OBU• 30th June 2006 - selection of modules and other components• 24th April 2006 - communication procedure developed• 31st May 2006 - production of the cloud model• 15th - 17th May 2006 - Testing of system by Morris Srl• 30th May 2006 - production of supplying module• 1st June 2006 - 15th June 2006 - the first remodelling of the quad tree model• 20th June 2006 - New generation of passenger counting system developed• 30th June 2006 - Morris Srl supplies Logina one analyzer• 3rd August 2006 - Quad tree model• 6th September 2006 - processing the commands accepted by the control centre• 11th August 2006 - Transfer of geographic data towards the OBU (.c2o files)• 22nd August 2006 - Production of users’ interface of the control centre• 15th September 2006 - change in the management of the data base• 20th September 2006 - Testing the second prototype casing• 26th September 2006 - Test of the OBU commands in controlled environment• 28th September 2006 - Test of the CC cell management with the assistance of the OBU• 1st October 2006 - storing data at engine off• 3rd October 2006 - the first test in a real environment (transfer of tolling maps in the

process of driving)


76


Key Milestones Achieved -2

• 10th October 2006 - The bus company Veolia from Ljubljana was selected for testing the traffic toll collection system. Veolia is a major bus company in Slovenia which has a daily bus line Ljubljana - Trieste – Ljubljana

• 12th October 2006 - Smartcard reader implementation• 17th October 2006 - the second test in the real environment (goal: detection of the

crossings through the stations)• 24th October 2006 - storing of unprocessed data into the memory card at engine off• 5th November 2006 - Installation was preformed in the first bus in Dvor by Novo Mesto• 7th November 2006 - encryption added• 9th November 2006 - authentication added• 8th November 2006 - We installed two OBUs into cars owned by Logina d.o.o

Other 7 devices are mobile and are separately installed into car which is going on test drive to certain route

• 12th November 2006 - Installation was preformed in a second bus in Dvor by Novo Mesto• 13th March 2007 - Change notice for Contract ref. GJU/06/2423/CTR/LMHC-TTCS

Extension of the period of execution of the tasks.• 15th March 2007 - The contract was extended until 31 May 2007.


77


Agenda

1. Description of the Project & Summary of Objectives2. Presentation of the planned programme and the work

undertaken3. Results of the design process and description of the


78


6.1 Next steps

• Wider-scale tests

• Enforcement• Disfunctional OBU• Vehicle without OBU• Fraud detection• Refusal of payment• Mobile enforcement units

• Better GNSS signal accuracy and availability (GALILEO promises both).

• Price reduction.

• Lower power consumption.

Basic requirements:

79


6.2 Commercialization

• Investors,

• Cellular network operators,

• Government,

Presentation of system to public and privacy awareness issues.

Interested parties:

80


Agenda



81


7.1 Main positive aspects

• Main goals of the project were reached.

• New Free-flow toll charging system is efficient enough to attract investors into further development.

• Promoting Galileo during the project

• Interests of the Slovenian government in the system.

• Growing number of GNSS applications.

• Galileo has strategic importance in the EU.

• Slovenia is a candidate to host the seat of the supervisor authority of the Galileo satellite navigation system.

• We are already developing a new version of the OBU for the Slovenian government

82


Agenda



83


• Projects that enable independence of a united Europe are of strategic importance. One of these is definitely Galileo. Despite our small size we are aware of this in Slovenia as well. We put a lot of energy into establishing Galileo headquarters here and we hope that our efforts will be rewarded.

• We are pleased to be part of such an important project like Galileo and we hope to be actively involved into a similar development project.

• We would like to thank everybody involved, the consortium partners and especially Mr. Jenkins, Mr. Boucher, Mr. Guyader and Mr. Ciliv for their cooperation, help and advice.

8.1 Conclusions

84


8.2 Contact details

Damjan Štrucl Rainer SchneiderLogina d.o.o. Hamburg Consult GmbHVodnikova cesta 252 Spohrstraße 6SI-1000 Ljubljana D-22083 HamburgSlovenia GermanyTel: +386-1-583-9460 Tel:[email protected] [email protected] www.hamburg-consult.de

Eugenio Moretti Marijan ŽuraMoretti S.r.l. Traffic Technical InstituteVia A. Rebez, 51 Jamova 2I-34075 San Canzian d’Isonzo SI-1000 LjubljanaItaly SloveniaTel: +39-0481-470150 Tel: +386-1-476 [email protected] [email protected] address: in construction www.pti.fgg.uni-lj.si

85


• D2.1 – Physical set up of the control center

• D2.2 – Development of 9 working prototypes

• D2.3 – 2 working prototypes passenger monitoring system

• D2.4 – Installation of prototypes into vehicles

• D3.1 – Communitcation software

• D3.2 – Cross calculation software

• D3.3 – Toll payment software

• D3.4 – SW for Evaluation

• D3.5 – Electronic map

• D4.1 – Hardware tehcnical documentation

• D4.2 – Software technical documentation

References to deliverables

Documents

Brussels, 22 nd of May 2007 1 Freeflow tolling system Including passenger monitor system GJU Contract No.: GJU/06/2423/CTR/LMHC-TTCS