STATE OF TECHNOLOGY AND
END-USER REQUIREMENTS
GINA : GNSS FOR INNOVATIVE ROAD
APPLICATIONS
Prepared by:
SKY, ICC, NW, CEN, ARV, AEN
Approved by:
Sara Gutiérrez Lanza (GMV)
Authorized by:
Carlos Barredo Abellón (GMV)
Filename :
GINA_SKY_StateofTechnologyandEndUserRequirements_D2 1_v2.0
Code :
GINA/D2.1
Version:
2.0
Date:
15/09/2009
WP:
WP2.1
Category*:
PU
Customer:
GSA
Grant Agreement:
227725
Internal code:
GMVSIS 20213/09 V1/09
*
PU Public / PP Program Participant / RE Restricted / CO Confidential
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
2 of 151
DOCUMENT STATUS SHEET
Version
Date
Pages
1.0
17/07/2009
154
2.0
15/09/2009
151
GINA
Changes
Updated with comments received from GSA and Sverker Almqvist
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
3 of 151
TABLE OF CONTENTS
DOCUMENT STATUS SHEET .................................................................................................................. 2
TABLE OF CONTENTS............................................................................................................................ 3
LIST OF TABLES AND FIGURES.............................................................................................................. 7
1. INTRODUCTION ................................................................................................................................ 8
1.1. PURPOSE ................................................................................................................................ 8
1.2. SCOPE .................................................................................................................................... 8
1.3. DEFINITIONS AND ACRONYMS ................................................................................................. 8
1.3.1. DEFINITIONS .................................................................................................................................... 8
1.3.2. ACRONYMS ....................................................................................................................................... 8
2. REFERENCES .................................................................................................................................. 10
2.1. APPLICABLE DOCUMENTS ...................................................................................................... 10
2.2. REFERENCE DOCUMENTS ....................................................................................................... 10
3. BACKGROUND ................................................................................................................................ 11
3.1. SATELLITE NAVIGATION IN THE ROAD AREA ........................................................................... 11
4. STATE OF TECHNOLOGY .................................................................................................................. 12
4.1. ROAD USER CHARGING ......................................................................................................... 12
4.1.1. OVERVIEW OF ROAD USER CHARGING EUROPEAN INITIATIVES RELEVANT TO GINA .......................... 13
4.1.1.1. Motorway Tolling ................................................................................................. 13
4.1.1.1.1. Via Verde (Portugal) ................................................................................... 13
4.1.1.1.2. VIA-T (Spain) ............................................................................................ 14
4.1.1.1.3. Telepass (Italy) ......................................................................................... 14
4.1.1.1.4. Liber-T (France)......................................................................................... 14
4.1.1.2. Heavy Vehicle Charging ....................................................................................... 15
4.1.1.2.1. LSVA (Switzerland) .................................................................................... 15
4.1.1.2.2. Toll Collect (Germany) ................................................................................ 17
4.1.1.2.3. MYTO-CZ (Czech Republic) [RD.14].............................................................. 18
4.1.1.2.4. GO (Austria) [RD.4] ................................................................................... 19
4.1.1.2.5. Slovakia [RD.6] ......................................................................................... 20
4.1.1.2.6. TIS-PL (France) ......................................................................................... 20
4.1.1.2.7. Slovenia ................................................................................................... 21
4.1.1.2.8. ARENA (Sweden) ....................................................................................... 21
4.1.1.3. Urban Charging ................................................................................................... 22
4.1.1.3.1. London Congestion Charge (United Kingdom) ................................................ 22
4.1.1.3.2. Stockholm Congestion Charging System (Sweden) ......................................... 23
4.1.1.3.3. Ecopass (Italy) .......................................................................................... 23
4.1.1.3.4. Oslo Toll Ring (Norway) .............................................................................. 23
4.1.1.4. The Dutch System ............................................................................................... 24
4.1.1.4.1. ABvM ....................................................................................................... 24
4.1.1.5. RUC Initiatives Summary ..................................................................................... 26
4.1.2. OVERVIEW OF R&D ROAD USER CHARGING EUROPEAN INITIATIVES RELEVANT TO GINA ................... 26
4.1.2.1. Congestion charging technology trials (TfL) [RD.8][RD.9] ........................................ 27
4.1.2.2. ARMAS (ESA)...................................................................................................... 31
4.1.2.3. GIROADS (GSA) [RD.13]...................................................................................... 33
4.1.2.4. VeRT (GSA) [RD.16] ............................................................................................ 34
4.1.2.5. CURACAO ........................................................................................................... 35
4.1.2.6. CESARE ............................................................................................................. 36
4.1.2.7. RCI ................................................................................................................... 38
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
4 of 151
4.1.2.8. MISTER .............................................................................................................. 40
4.1.2.9. U-OBU ............................................................................................................... 41
4.1.2.10. RUC R&D initiatives summary ............................................................................. 42
4.1.3. STANDARDS AND INTEROPERABILITY INITIATIVES RELEVANT TO GINA ............................................. 42
4.1.3.1. Standards relevant to GNSS-based RUC ................................................................. 42
4.1.3.1.1. ISO TS 17575............................................................................................ 43
4.1.3.1.2. TS 17573 .................................................................................................. 45
4.1.3.1.3. TS 12855 .................................................................................................. 45
4.1.3.1.4. TS 12813 and TS 13143 ............................................................................. 45
4.1.3.1.5. TS 13141 and TS 13140 ............................................................................. 46
4.1.3.2. The Eurovignette Directive [RD.15] ....................................................................... 46
4.1.3.3. The interoperability directive and the EETS ............................................................. 47
4.1.3.4. Standards and Interoperability Summary ............................................................... 49
4.2. VALUE ADDED SERVICES ....................................................................................................... 50
4.2.1. OVERVIEW OF PAYD AND OTHER VAS SOLUTIONS RELEVANT TO GINA.............................................. 51
4.2.1.1. Pay As You Drive (PAYD) ...................................................................................... 51
4.2.1.1.1. PWYD (Portugal) ........................................................................................ 51
4.2.1.1.2. Proyecto Generación Y (Y-CAR) (Spain) ........................................................ 52
4.2.1.1.3. Maaf (France) ............................................................................................ 52
4.2.1.1.4. Norwich Union (United Kingdom) ................................................................. 52
4.2.1.1.5. Hollard (South Africa) ................................................................................. 53
4.2.1.1.6. MyRate - Progressive (USA) ........................................................................ 53
4.2.1.2. Traffic Management and Information ..................................................................... 53
4.2.1.2.1. RITA (Portugal) ......................................................................................... 54
4.2.1.2.2. ADvantis (GSA) ......................................................................................... 55
4.2.1.2.3. MORYNE [RD.12] ....................................................................................... 57
4.2.1.3. Other VAS .......................................................................................................... 58
4.2.1.3.1. COOPERS.................................................................................................. 58
4.2.1.3.2. GST ......................................................................................................... 59
4.2.1.3.3. COM2REACT .............................................................................................. 60
4.2.1.3.4. GOODROUTE ............................................................................................. 60
4.2.1.4. VAS Solutions Summary ...................................................................................... 61
4.2.2. STANDARDS AND INTEROPERABILITY INITIATIVES RELEVANT TO GINA ............................................. 61
4.3. LESSONS LEARNED, POTENTIAL RISKS AND MITIGATION STRATEGIES .................................... 61
4.3.1. RELEVANT ISSUES ENCOUNTERED IN OTHER PROJECTS ................................................................... 61
4.3.1.1. General Issues Encountered ................................................................................. 61
4.3.1.2. Specific RUC Issues Encountered ........................................................................... 66
4.3.2. POTENTIAL RISKS AND MITIGATION STRATEGIES............................................................................. 68
4.3.3. LESSONS LEARNED SUMMARY ......................................................................................................... 68
4.4. OVERVIEW OF OTHER TECHNOLOGIES RELEVANT TO GINA ..................................................... 70
4.4.1. ANPR .............................................................................................................................................. 70
4.4.2. DSRC.............................................................................................................................................. 70
4.4.3. VEHICLE’S ON-BOARD DIAGNOSTIC SYSTEM.................................................................................... 71
4.4.4. CONTROLLER AREA NETWORK BUS (CAN-BUS)................................................................................. 71
4.4.5. MOBILE COMMUNICATION PROTOCOLS............................................................................................ 72
4.4.5.1. GSM/GPRS ......................................................................................................... 72
4.4.5.2. UMTS................................................................................................................. 73
4.4.5.3. VANET ............................................................................................................... 73
4.4.5.4. CALM ................................................................................................................. 74
4.4.6. EGNOS USAGE WITHOUT SATELLITE LINK ........................................................................................ 75
4.4.7. EGNOS DATA ACCESS SYSTEM (EDAS)............................................................................................. 76
4.4.8. OTHER TECHNOLOGIES SUMMARY ................................................................................................... 77
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
5 of 151
5. END-USER REQUIREMENTS ............................................................................................................. 79
5.1. INTRODUCTION..................................................................................................................... 79
5.1.1. PROJECT / SYSTEM OBJECTIVES....................................................................................................... 79
5.1.2. END-USER DEFINITION .................................................................................................................... 79
5.1.3. KEY DESIGN PARAMETERS AND ASSUMPTIONS................................................................................. 80
5.1.4. STRUCTURE OF REQUIREMENTS DOCUMENTATION ........................................................................... 81
5.1.5. METHODOLOGY ............................................................................................................................... 82
5.1.6. SUMMARY ....................................................................................................................................... 83
5.2. SYSTEM OVERVIEW ............................................................................................................... 84
5.3. PRIVACY ............................................................................................................................... 84
5.3.1. OVERVIEW ...................................................................................................................................... 84
5.3.2. IMPLICATIONS OF DUTCH REQUIREMENTS ....................................................................................... 85
5.3.3. PRIVACY REQUIREMENTS................................................................................................................. 86
5.3.4. SUMMARY ....................................................................................................................................... 88
5.4. SERVICES ............................................................................................................................. 89
5.4.1. INTRODUCTION............................................................................................................................... 89
5.4.2. ROAD USER CHARGING - OVERVIEW ................................................................................................ 89
5.4.2.1. Tariffing by road use............................................................................................ 90
5.4.2.2. Tariffing by vehicle use – pay as you drive ............................................................. 92
5.4.2.3. Tariff structure information requirements ............................................................... 93
5.4.3. ROAD USER CHARGING - SUMMARY ................................................................................................. 94
5.4.4. ROAD USER CHARGING - REQUIREMENTS ........................................................................................ 95
5.4.5. VALUE-ADDED SERVICES - PAY AS YOU DRIVE - REQUIREMENTS ...................................................... 98
5.4.6. VALUE-ADDED SERVICES - AGGREGATE SERVICES - OVERVIEW...................................................... 101
5.4.6.1. Introduction ..................................................................................................... 101
5.4.6.2. Government / TC policies and strategies .............................................................. 102
5.4.6.3. INFORMATION REQUIREMENTS ........................................................................... 104
5.4.6.4. Summary ......................................................................................................... 109
5.4.7. VALUE-ADDED SERVICES - AGGREGATE SERVICES - REQUIREMENTS .............................................. 109
5.4.8. VALUE-ADDED SERVICES - SPECIFIC SERVICES .............................................................................. 111
5.5. BILLING REQUIREMENTS ..................................................................................................... 113
5.6. END TO END PERFORMANCE REQUIREMENTS........................................................................ 115
5.7. OBU.................................................................................................................................... 117
5.7.1. OBU PHYSICAL REQUIREMENTS ..................................................................................................... 117
5.7.2. OBU FUNCTIONAL REQUIREMENTS ................................................................................................. 118
5.7.2.1. Position Determination ....................................................................................... 118
5.7.2.2. Security ........................................................................................................... 119
5.7.2.3. Interface to SP .................................................................................................. 121
5.7.2.4. Tolling ............................................................................................................. 123
5.7.2.5. Compliance ...................................................................................................... 125
5.7.2.6. Services ........................................................................................................... 125
5.7.3. OBU PERFORMANCE REQUIREMENTS.............................................................................................. 127
5.8. OBU SUPPORT SERVICE ....................................................................................................... 128
5.9. CUSTOMER RELATIONSHIP MANAGEMENT (CRM) SYSTEM ..................................................... 128
5.9.1. INTRODUCTION............................................................................................................................. 128
5.9.2. CRM FUNCTIONALITY..................................................................................................................... 129
5.10. COMPLIANCE / ENFORCEMENT............................................................................................ 133
5.10.1. OVERVIEW .................................................................................................................................. 133
5.10.2. COMPLIANCE REQUIREMENTS ...................................................................................................... 134
5.11. TC / SP TO DRIVER COMMUNICATIONS ............................................................................... 137
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
6 of 151
5.12. REQUIREMENTS SUMMARY ................................................................................................. 141
5.12.1. PRIVACY...................................................................................................................................... 141
5.12.2. ROAD USER CHARGING ............................................................................................................... 142
5.12.3. VALUE-ADDED SERVICES - PAY AS YOU DRIVE ............................................................................. 143
5.12.4. VALUE-ADDED SERVICES - AGGREGATE SERVICES ....................................................................... 143
5.12.5. VALUE-ADDED SERVICES - SPECIFIC SERVICES ............................................................................ 144
5.12.6. BILLING ...................................................................................................................................... 144
5.12.7. CHARGING PERFORMANCE........................................................................................................... 144
5.12.8. OBU PHYSICAL REQUIREMENTS ................................................................................................... 144
5.12.9. OBU FUNCTIONAL REQUIREMENTS ............................................................................................... 145
5.12.10. OBU PERFORMANCE REQUIREMENTS .......................................................................................... 147
5.12.11. CRM FUNCTIONALITY ................................................................................................................. 147
5.12.12. COMPLIANCE ............................................................................................................................. 147
6. CONCLUSIONS ............................................................................................................................. 149
END OF DOCUMENT.......................................................................................................................... 151
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
7 of 151
LIST OF TABLES AND FIGURES
Table 1-1 – Definitions .............................................................................................................. 8
Table 1-2 – Acronyms ............................................................................................................... 9
Table 2-1 – Applicable documents ............................................................................................ 10
Table 2-2 – Reference documents ............................................................................................ 10
Table 4-1 – Motorway tolling initiatives ..................................................................................... 13
Table 4-2 – HVG tolling initiatives............................................................................................. 15
Table 4-3 – urban tolling initiatives........................................................................................... 22
Table 4-4 – R&D RUC initiatives ............................................................................................... 27
Table 4-5 – Overview of the project teams PT20-PT32 ................................................................ 43
Table 4-6: Cost comparison estimate for Kilometre-charging systems (M€) ................................... 62
Table 4-7: Road Network complexity – cost relation (M€) ............................................................ 63
Table 4-8 – Identified risks and mitigation strategies .................................................................. 68
Table 4-9 – Lessons learned summary ...................................................................................... 69
Figure 4-1 - Border crossings recorded with DSRC ...................................................................... 16
Figure 4-2 – Toll Collect system overview .................................................................................. 17
Figure 4-3 - Current London Congestion Charging zone ............................................................... 22
Figure 4-4 – Account from TfL's DBC Trials ................................................................................ 29
Figure 4-5 – “ARMAS” overall architecture ................................................................................. 32
Figure 4-6 – “Charge objects” or “Geo-objects” in GNSS-based EFC systems ................................. 32
Figure 4-7 – GIROADS High Level Architecture ........................................................................... 33
Figure 4-8 – CESARE EETS model ............................................................................................. 38
Figure 4-9 – Roles and service components ............................................................................... 38
Figure 4-10 – Assumed technical architecture and interfaces ....................................................... 44
Figure 4-11 – Roles in the Toll Charging environment ................................................................. 45
Figure 4-12 – Compliance Check Communication in the EFC architecture of prEN ISO 17573 ........... 46
Figure 4-13 – CESARE EETS model ........................................................................................... 48
Figure 4-14 – CESARE EETS model ........................................................................................... 48
Figure 4-15 – RITA Map Interface ............................................................................................. 55
Figure 4-16 – ADvantis architecture.......................................................................................... 56
Figure 4-17 – MORYNE architecture .......................................................................................... 57
Figure 4-18 – COOPERS architecture ........................................................................................ 59
Figure 4-19 – Road Network complexity – cost relation (M€) ....................................................... 64
Figure 4-20 – CALM System Overview ....................................................................................... 75
Figure 4-21 – Sisnet Architecture ............................................................................................. 76
Figure 4-22 – EDAS Architecture .............................................................................................. 77
Figure 5-1: Key system elements ............................................................................................. 84
Figure 5-2: Structure of value pricing measures (Source: Salas, 2008) ......................................... 90
Figure 5-3: Qualitative impact of different measure on different policies (Kocak, 2002) ................. 103
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
8 of 151
1. INTRODUCTION
1.1. PURPOSE
The purpose of this document is to deal with the analysis of the state of technology for road pricing
and other value added services (mainly PAYD and Traffic Information Generation, modeling and
provision) and end-user requirements for these applications.
1.2. SCOPE
This document contains a state of technology study regarding road user charging and value added
services in the area of GNSS in the road sector.
1.3. DEFINITIONS AND ACRONYMS
1.3.1. DEFINITIONS
Concepts and terms used in this document and needing a definition are included in the following table:
Concept / Term
no relevant definitions to be
highlighted in this document
Definition
no relevant definitions to be highlighted in this document
Table 1-1 – Definitions
1.3.2. ACRONYMS
Acronyms used in this document and needing a definition are included in the following table:
Acronym
Definition
3G
Third Generation
3GSM
Third Generation GSM Services
ABVM
Anders Betalen voor Mobiliteits
AGILE
Application of Galileo in the LBS Environment
ANPR
Automatic Number Plate Recognition
ARMAS
Active Road Management Assisted by Satellite
CALM
Communication Access for Land Mobiles
CAN
Controller Area Network
CEN
European Committee for Standardisation
CESARE
Common Electronic Fee Collection System for an ASECAP Road Tolling European Service
DSRC
Dedicated Short Range Communications
EGNOS
European Geostationary Navigation Overlay Service
EOBD
European On Board Diagnostics
ETC
Electronic Toll Collection
ESA
European Space Agency
GINA
GNSS for Innovative Road Applications
GIROADS
GNSS Introduction in the ROAD Sector
GJU
Galileo Joint Undertaking
GNSS
Global Navigation Satellite Systems
GPRS
General Packet Radio Service
GPS
Global Positioning System
GSA
European GNSS Supervisory Authority
GSM
Global System for Mobile communication
HGV
Heavy Goods Vehicle
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Acronym
D2.1
15/09/2009
2.0
9 of 151
Definition
LBS
Location Based Services
MISTER
Minimum Interoperability Specification for Tolling on European Roads
MLFF
Multi Lane Free Flow
OBE
On Board Equipment
OBU
On Board Unit
PAYD
Pay As You Drive
PT
Project Team
PWYD
Pay What You Drive
RCI
Road Charging Interoperability
RITA
Road Intelligent Traffic Application
RUC
Road User Charging
UCP
Urban Charge Point
UMTS
Universal Mobile Telecommunications System
VANET
Vehicular Ad-hoc Network
VAS
Value Added Services
Table 1-2 – Acronyms
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
10 of 151
2. REFERENCES
2.1. APPLICABLE DOCUMENTS
The following documents, of the exact issue shown, form part of this document to the extent specified
herein. Applicable documents are those referenced in the Grant Agreement or approved by the
Approval Authority. They are referenced in this document in the form [AD.X]:
Ref.
Title
Code
Version
Date
[AD.1]
GINA Template for documents
V1.0
09/05/2009
[AD.2]
“GINA: GNSS for Innovative applications” proposal, part B
GINA_PartB
2.0
14/11/2008
[AD.3]
Grant Agreement
227725
1.0
12/06/2009
Table 2-1 – Applicable documents
2.2. REFERENCE DOCUMENTS
The following documents, although not part of this document, amplify or clarify its contents. Reference
documents are those not applicable and referenced within this document. They are referenced in this
document in the form [RD.X]:
Ref.
Title
Code
Version
Date
[RD.1]
ARMAS Phase III State of the Art Technology Study
Dec-2006
[RD.2]
Safety Applications of Intelligent Transportation Systems in
Europe and Japan
Jan-2006
[RD.3]
GNSS ‘superoperability’ changes the incumbent tolling
landscape
[RD.4]
Austria’s Nationwide Truck Tolling System
[RD.5]
NORITS – Nordic Interoperable Tolling Systems
[RD.6]
Satellite-based toll collection in Slovakia
Mar-2007
[RD.7]
Special session on road charging: Lessons learned and the way
forward – 2009 Mobile Solutions Congress
Apr-2009
[RD.8]
Report on Transport for London’s GPS OBU Trial
Oct-2006
[RD.9]
Congestion Charging Technology Trials – Stage 3 Final Report
Jul-2008
[RD.10]
Socio-technical research of electronic tolling systems in Europe,
and which to use in the Netherlands
Oct-2005
[RD.11]
UK GNSS Downstream Benefits Assessment – 2007 Final Report
Dec-2007
[RD.12]
MORYNE – Synthesis of State-of-the-art and User Requirements
Apr-2008
[RD.13]
GIROADS Final Report
Fev-2008
[RD.14]
Czech Nationwide Truck e-Toll System
[RD.15]
HGV Road toll models in European Union countries considering
Eurovignette directive
[RD.16]
VERT: EGNOS campaign results analysis toward a multiservice
platform in the transport doman
[RD.17]
Special Knowledge Group ABvM – Report round table
discussions SKG ABvM
Apr-2008
[RD.18]
ABvM – Requirement Specification
Mar-2006
[RD.19]
Call for tender Kilometre Price System
Dec-2008
Table 2-2 – Reference documents
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
11 of 151
3. BACKGROUND
3.1. SATELLITE NAVIGATION IN THE ROAD AREA
The market for in-car satellite navigation devices continues to grow. With the implementation of
EGNOS and in time Galileo, having a certified and improved European navigation system opens the
road market and stimulates the development of numerous safety and road demand management
applications.
Nowadays, the number of passenger car fleet is rising all over Europe and this growth is becoming
problematic, especially in highly populated areas. As a result, authorities are facing several challenges
regarding the need for increased road safety, improved road infrastructure and reduction of
congestion and pollution.
The use of applications based on Galileo/EGNOS can be key in reducing the negative impact of road
transport, either in road safety terms, funding of road infrastructure, congestion or environment
issues.
Satellite navigation already has several applications in the road area. Some examples are:

Satellite navigation devices – that aim to aid drivers, by allowing to plan routes before starting
a trip, choosing the best route according to the driver selected parameters, assisting the
driver with traffic information, like congestion updates or speed limits;

Fleet management systems – allowing truck companies to keep track on their trucks and
cargo, being able to provide remote assistance, for example, by calling the authorities in case
of an accident and providing the accident location.

Pay-As-You-Drive solutions – allowing insurance and car leasing companies to charge their
customers according to their driving behaviours, such as: average speed, speed limits
compliance, distance driven, geographical area driven, etc.
Currently, several initiatives are taking satellite navigation a step further, by exploring its potential in
emerging areas, like Road User Charging (RUC), Pay-As-You-Drive (PAYD), and other Value Added
Services (VAS).
With the adoption of satellite navigation in these areas, new possibilities arise that may lead to
solutions focused on evolving the road sector by creating safer, cleaner, cheaper and more efficient
solutions.
The GINA project is addressing the adoption of EGNOS and Galileo in the road sector considering the
technical feasibility of the concept on a large scale, its economic viability and positive impacts in
aspects such as congestion and pollution, as a general scope.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
12 of 151
4. STATE OF TECHNOLOGY
4.1. ROAD USER CHARGING
The passenger car fleet is growing throughout Europe and this growth becomes especially critical in
highly populated areas such as big cities and regions. The use of Satellite Navigation Devices (SND) is
booming and this booming is creating a platform for applications beyond navigation. The situation
faces major challenges such as the increase of safety on roads, funding of road infrastructure and
reduction of congestion and pollution.
Different schemes are being proposed to improve the situation. Of particular interest is road pricing,
which is expected to generate wide public benefits through the reduction of road congestion and
pollution (which is an EU priority). In this context, Galileo and EGNOS, as improved GNSS
infrastructure to support road pricing, can be key to reduce the negative impact of road transport and
offer new business opportunities.
Road User Charging (RUC) refers to a variety of methods for charging road users, varied by both
policy and technology. The technology is currently available in three areas, satellite navigation, RFID
or tag and beacon, and video detection. The policy factors driving such charging are numerous and
these include congestion charging, road taxation and road tolling. It can also form a larger scheme to
charge for use of road space, and provide a means through which road space can be re-allocated in
favour of public transport.
In order to charge the road usage there are several possible forms of road pricing:

Area licensing - allows for provision of a license, which enables the user to drive within a
certain defined area.

Cordon/zone charging - involves setting up a linear cordon and charging at access points to
the zone.

Distance-based charging - the fee levied is proportional to the distance travelled.

Time-based charging - the driver is charged a fee related to how much time is spent on
charged roads.

Congestion charging – is a term applied to urban road pricing where users are charged for
the use of a specific section of the road network, or Congestion Charge Zones.
There are also various ways of charging:

Toll collection – at booths.

Automatic number-plate recognition (ANPR) - camera takes photo of car and generates a
debit to an account or a charge levied on a user (as in the case of Stockholm)

Electronic Fee Collection (EFC):
o
Dedicated Short-Range Communication (DSRC) based - the beacon communicates with
the on-board unit and deducts payment from its memory, or by generating a charge to
an account within the charging system. More details on DSRC technology in chapter
4.4.2.
o
Satellite Positioning based.
This chapter presents an overview of some past and present European initiatives regarding road user
charging, covering the following types of tolling:

Motorway Tolling – presenting some already implement and functioning European initiatives.

Heavy Vehicles Tolling – presenting various European initiatives aligned with the
Eurovignette Directive.

Urban Congestion Charging – presenting various European initiatives for charging within
urban areas.

The Dutch System – presenting a solution for all vehicle types in any type of road.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
13 of 151
In this chapter are also described some European R&D projects that contributed to the feasibility and
maturity analysis of current technology, when applied to road user charging:

ARMAS (ESA)

GIROADS (GSA)

VeRT (GSA)

CURACAO

CESARE I to IV

RCI

MISTER

U-OBU
4.1.1. OVERVIEW OF ROAD USER CHARGING EUROPEAN INITIATIVES
RELEVANT TO GINA
4.1.1.1. Motorway Tolling
This chapter describes several operational European initiatives regarding motorway tolling:
Title
Technology
Country
Year
Link
Via Verde
DSRC
Portugal
1991
www.viaverde.pt
Via-T
DSRC
Spain
2000
www.viat.es
Telepass
DSRC
Italy
1989
www.telepass.it
Liber-T
DSRC
France
www.sanef.com/fr/ecommerce/particulier/decouvre.jsp
Table 4-1 – Motorway tolling initiatives
One noticeable characteristic common to them all is the technology adopted for the implementation of
each system – DSRC. Due to the low complexity of motorway networks and the relative low cost of
DSRC implementation in this scenario, it has been adopted by the majority of European countries for
their tolling systems. Along the years there has been some innovation like the appearance of MLFF
(Multi Lane Free Flow) systems in contrast to older SLFF (Single Lane Free Flow) systems.
The following sections present examples of motorway tolling using DSRC as the main tolling
technology.
4.1.1.1.1. Via Verde (Portugal)
The “Via Verde” toll payment system allows a virtual payment model involving all the Portuguese
motorways and bridge operators since 1991 and was recently extended (2002) with automatic
payments in gas stations and car parking lots.
The Portuguese motorway and bridges use a single lane model based on fixed toll infrastructures
where cars have to cross a “Via Verde” (non-stop lanes) or a manual lane where an operator accepts
coins or an electronic payment card. The multi-lane toll model while used in other countries was not
until now adapted to the Portuguese motorways considering the legal model that regulate the toll fee
collection.
A toll infrastructure for a Via-Verde lane involves a DSRC system, a car classification system, a display
to show status information and sometimes an enforcement system based on vehicle license plate
recognition. The system allows interoperability among several concessions that are responsible for the
roads management.
In the near future (end of 2009), a new system based on the Via Verde solution will begin working
and progressively substitute all highway toll booth plazas and Via Verde. The main difference from the
current Via Verde is that this new system will be multi-lane free flow instead of the current single-lane
free flow solution. DSRC-based OBUs will also become mandatory for all Portuguese drivers.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
14 of 151
4.1.1.1.2. VIA-T (Spain)
The VIA-T is an electronic toll system used in the Spanish toll road to pay for the trip without stopping
the vehicle, thanks to a device that is placed in the car and another electronic device reading at toll
stations, automatically manages the opening of the security barrier and payment. The maximum
speed allowed to pass through the toll barrier is 40 km/h, faster one runs the risk that the barrier
does not have time to open and collision with it.
VIA-T is composed by an OBU that uses DSRC protocol to communicate with the toll booth when the
user passes through it. The OBU is not linked to the vehicle but to the user.
4.1.1.1.3. Telepass (Italy)
Telepass is the brand name for an electronic toll collection system used to collect toll on motorways in
Italy. The system was introduced in 1989 and is not interoperable, at any level, with any other DSRC
system in Europe.
There are three main Telepass implementations:

Telepass Family, which can be used with a current or a credit card account,

Telepass with ViaCard, which can be used with a ViaCard toll charge card linked to a current or
credit card account,

Telepass Ricaricabile, which does not require a current or credit card account.
Telepass can be used for all types of vehicles which can travel on Italian motorways. Telepass consists
of an On-Board Unit (OBU) mounted at the top of the vehicle's windscreen. The OBU is batterypowered. Telepass Family and Telepass with ViaCard OBUs need to be replaced after approx. three
years. Telepass Ricaricabile OBUs have user-replaceable batteries. The OBUs communicate with the
electronic toll booths by dedicated short-range communications.
Telepass is used on motorways in the open and the closed systems. Toll in the open system consists
of a flat fee charged for the use of a motorway or a part thereof, regardless of the distance travelled.
Toll in the closed system is charged depending on the distance. In both systems, the toll varies
according to the type of vehicle (car, bus, lorry etc.) and to the upkeep for the motorway.
Telepass is currently available on most motorway entries and exits. At large toll stations, all lanes,
including lanes supervised by toll cashiers, are equipped for Telepass use, at smaller stations, there
are special Telepass-only lanes and lanes for Telepass and ViaCard use.
Telepass Ricaricabile (rechargeable) was introduced in March 2006 in the Naples area in
southern Italy. It is currently being tested for reliability and is eventually to be available on
all Italian motorways which support Telepass family. For Telepass Ricaricabile, the user is
required to make pre-payments in person, by phone or on-line. No current or credit card
accounts are required, and Telepass Ricaricabile is therefore of special interest to foreign
visitors. Telepass Ricaricabile uses an OBU different from the other Telepass versions.
Telepass is not interoperable, at any level, with other DSRC systems in Europe
4.1.1.1.4. Liber-T (France)
Similar to other European toll collection systems, the Liber-T is used on highways across France as a
national ETC system for light vehicles, interoperable with the other toll concession networks in France.
In 2007, the Liber-T system was extended to support heavy vehicles. From this process TIS-PL was
born.
One of the main objectives of Liber-T was to provide transparency among the tollways and make
travelling around France more simple.
The system consists of a DSRC receptor and a road barrier installed on toll sites, usually on the left
lane of the road, next to the remaining conventional toll booths.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
15 of 151
To use the Liber-T system, a vehicle must have an OBU installed which communicates via DSRC with
the receptor installed on the highways. When a valid ID is read on the receptor, the barrier is lifted,
allowing the vehicle to pass. Information is passed to a central system where a single invoice will be
generated with all the tolls accumulated.
Incentives are given to users, like discounts depending on the frequency of travelling; free travels
when a determined number of travels is made on the same highway a month.
4.1.1.2. Heavy Vehicle Charging
This chapter presents various implemented European initiatives considering the charging of Heavy
Goods Vehicles (HGV), which are aligned with the Eurovignette Directive [RD.16]:
Title
Technology
Country
Year
Link
LSVA
DSRC
Switzerland
2001
Toll Collect
GNSS
Germany
2005
www.toll-collect.de
MYTO-CZ
DSRC
Czech Republic
2007
www.premid.cz
GO
DSRC
Austria
2004
www.go-direkt.at
Slovakia
GNSS
Slovakia
2010
TIS-PL
DSRC
TIS-PL
2007
Slovenia
GNSS
Slovenia
>2010
ARENA
GNSS
Sweden
2010-2012
www.tis-pl.com
www.arena-ruc.com
Table 4-2 – HVG tolling initiatives
4.1.1.2.1. LSVA (Switzerland)
The Swiss parliament drew a federal law that wanted to replace the since 1985 existing flat fee for
Heavy Goods Vehicles (HGV) by a nation-wide distant-related fee, the LSVA (Leistungsabhängige
Schwerverkehrsabgabe). A referendum on the proposed law was called. In the subsequent plebiscite
on September 27, 1998, the Swiss people adopted the law with a large majority. Subsequently, the
LSVA started on January 1st 2001.
The main reasons and basic principles for the introduction of the LSVA were:

Internalization of external cost of heavy vehicle traffic (principle of true costs).

Shifting heavy vehicle traffic from road to rail and increasing the rail’s competitiveness.

Preventing the forecasted increase in heavy vehicles traffic.

Compensating for the increase in productivity due to the admission of 40-tons goods vehicles
that became legal after the bilateral treaties with the European Union.

Generating revenue for financing large-scale public transport projects, e.g. the New Alpine Rail
Transversal (NEAT).

Bringing the Swiss transit fee for crossing the Alps in line with the corresponding fees in
France and Austria, thus avoiding distortion of competition and ecologically undesirable
detours.
The basic principles of the LSVA are that it is distant-related (driving more means paying more) and
that empty vehicles cost as much as fully loaded ones. It is levied for HGV on all public roads,
including both urban and non-urban roads.
The LSVA is levied according to:

The number of kilometres driven on all public roads in Switzerland;

The maximum permissible laden weight (tons);

The emission category of the Heavy Goods Vehicles.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
16 of 151
This pricing structure aims at reducing overall transport distances and increasing vehicle capacity
usage. As the levied fee depends on the emission category of the vehicle too, the LSVA will also
influence the choice of vehicles towards environmentally friendlier solutions.
The fee collection is based on the principle of self-declaration. The liable person (vehicle owner or
driver) is obliged to actively participate. For domestic vehicles an On-Board-Unit (OBU) is mandatory.
Foreign vehicles basically are using a ticket fetched at self-service machines. The OBU records the
required trip data automatically. The distance is recorded by the tachograph. A GPS sensor and a
movement sensor provide a second, redundant measurement in order to make sure that the
tachograph signal is not intentionally interrupted or falsified. A Dedicated Short Range Communication
(DSRC) air-link is used to switch the recording of the kilometres on and off when crossing the border.
Radio beacons are installed over the carriageways at the 82 border crossings concerned.
Figure 4-1 - Border crossings recorded with DSRC
For foreign vehicles an ID-Card issued at the first entry provides for self-service on entry and
simplifies the processes on exit. When entering, the driver declares the relevant data (mileage
reading, trailer status, payment mode) at the self-serving machines and receives a ticket. The whole
declaration process takes less than 2 minutes. Domestic vehicles can drive for a long time within
Switzerland without ever crossing the border where the correctness of their recorded data is checked.
Therefore checks in the interior are indispensable in order to enforce a correct declaration. The checks
do not influence the moving traffic as they are done via the DSRC air link and by making use of the
externally visible lamps of the OBU. Vehicles with a wrong declaration, e.g. a missing trailer
declaration, can be sued.
Domestic vehicle owners monthly declare the fee parameters (distances and weights) to the Swiss
Customs Authority SCA. The SCA processes the data, determines the amount due, invoices the vehicle
owner and collects the fee. Foreign vehicles declare their trip data when leaving Switzerland. The fee
may be settled via a petrol card or via an account held with the SCA. Immediate cash payment is also
possible.
The following key factors have been decisive for the LSVA’s success:

The project could build up on an existing organization, the Swiss Customs Authority.

A lot could be learned and improved in tests and field trials.

For public acceptance it was important that the project had been legitimated by the public vote
(i.e. heavily attacked before, but democratically accepted afterwards).
Main conclusions:
From the LSVA experiences the following general conclusions for electronic road pricing schemes can
be drawn:

GINA
Demand management through pricing measures works (although high charges are needed to
produce considerable effects).
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
17 of 151

The impacts are not fully predictable (the market will adapt to pressure, but possible reactions
are manifold).

Processes come before technology: technical solutions have to follow the problem not viceversa.

It is the procedures for the non-equipped, badly informed user that decide whether a system
works or not.
4.1.1.2.2. Toll Collect (Germany)
The German government has implemented a GNSS based toll system for trucks. An overview of the
entire system is shown in the figure below.
Figure 4-2 – Toll Collect system overview
The system is designed to operate with an On Board Unit (OBU) in the truck. The OBU contains:

A GPS sensor for automatic position determination;

An infrared communication device to communicate with support beacons for more precise
position determination, and with enforcement units for compliance checking;

A gyroscopic device, and a link to the tachometer for dead-reckoning;

A GSM mobile telephone;

A map of Germany, indicating virtual toll points;

A user interface to set parameters such as number of axis of the truck, accounting codenumber, start of new tour.
The OBU sends the amount of toll to be paid with the mobile system, after a predefined period, or
after the maximum amount has been reached.
For enforcement, fixed control bridges and mobile control units are used. The control bridges span the
entire road and determine whether a passing vehicle is required to pay toll and if the toll has been
duly paid. Each vehicle that approaches the control bridge is recorded by a detection and tracking
unit, which determines in which lane and at what precise time the vehicle passes the bridge. This
ensures that the vehicle can be properly classified. The automated control bridges use DSRC
(Dedicated Short Range Communications) technology to determine whether the vehicle is participating
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
18 of 151
in the automatic toll collection system and if the On-Board Unit has been properly activated. If a
vehicle subject to toll is not emitting an infrared signal, it has either logged on manually or is in
violation. The number plate of each vehicle is photographed with an infrared camera and compared
with the logged on number plate at Toll Collect headquarters. (The number plate must be input during
manual log-on over the Internet or at a toll station terminal.) After the vehicle is identified, it is
determined whether it is required to pay toll, that is, if its total permissible weight is 12 tons or more.
For this purpose, each vehicle is scanned three-dimensionally. The assessment technology recognizes
the contour of the vehicle and determines whether it is required to pay toll and how many axles it has.
If no toll is due, the data is immediately deleted.
The successful operation of the German toll-collect system is a major achievement. Probably because
it was the first such system, the development costs were much higher than originally anticipated and
the introduction was delayed from august 2003 to January 2005. Several engineering decisions have
been made that may not be repeated in another implementation of a similar system. Here is a list of
relevant points raised by Toll Collect:

Accuracy of positioning - During the project it turned out that the GPS positioning system
was not sufficiently accurate for all cases. Thus it was decided that gyroscopes and odometers
would be used for road segments identification that is the main input for the charging
computation. In addition, difficult cases include the presence of a road parallel to the highway,
where the parallel road does not require toll payment, but the highway does. Because of this,
180 support beacons needed to be set up permanently, to communicate by infrared the
precise location to the truck.

Map updating - Because the OBU contains a map of Germany, indicating the virtual toll
points, there is a need to update this map regularly. The updating process has resulted in
huge (in some cases even unacceptable) loads on the GSM network.

Control and surveillance - The costs of surveillance are quite high in relationship to the total
amount of toll collected.

Back office - The back office system implementation has been hugely complex and
contributed its share to delays and costs overruns.

Cost of OBU installation - The OBU needs to be connected to various systems inside the
truck. The time to build the OBU into the truck is required to be less than 4 hours, which is
acceptable for trucks, but not acceptable for cars.

Limitation to highways (Autobahn) - As a response to the toll on highways, most truck
operators have included alternative road in their planning systems, whenever that made
economical sense (i.e. costs of delay on other road less than costs of toll). These so-called
‘Mautflüchtlinge’ have led to various local problems, and calls for the introduction of a toll
system that also applies to side roads, so that trucks will continue to use the Autobahn.
Main conclusions:
The main lessons that can be learned from the toll-collect implementation (apart from many nontechnical lessons) are:

The importance of precision (avoiding the need for additional technology that makes the OBU
complex and auxiliary beacons);

The limitation of technology for its application to secondary roads and urban tolling;

The need to carefully consider alternative trade-offs between OBU complexity, communication
costs, and central services;

The need for an alternative approach to back-office implementation.
Focusing Toll Collect system, it will be analyzed what are the issues which should be addressed if
satellite-based tolling would be extended to the whole Community.
4.1.1.2.3. MYTO-CZ (Czech Republic) [RD.14]
The Czech HGV toll system was introduced nationwide on January 1 st 2007 by the company Kapsch
TrafficCom, after the Czech government decided in March 2004 to implement an electronic toll
collection system for heavy trucks.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
19 of 151
MYTO-CZ is a multi lane free flow tolling system intended for vehicles with laden weight of 12 t or
above. The tolling fee is based on the distance travelled and is currently in effect on 970 km of
selected highways and motorways throughout the country.
Technically it consists of the installation of an OBU on the vehicles with pre-pay and post-pay
capabilities. The OBU uses a DSRC CEN TC278 compliant multilane free flow system to ensure
interoperability within Europe.
CEN TC278 is a Standards body responsible for DSRC related standards for EFC.
A pilot test has already occurred where a hybrid DSRC-GNSS implementation was used to allow
charging in road networks with limited capacity for roadside infrastructure.
Main Conclusions:
MYTO-CZ demonstrates that DSRC is a mature proven solution with high accuracy, enabling a fast a
solid return on investment. With the evolution to a more flexible DSRC-GNSS solution, the roadauthority will be able to accommodate new transport policies and tolling schemes in the future.
4.1.1.2.4. GO (Austria) [RD.4]
Austria’s was the first to implement a nation wide multi-lane free flow electronic toll system.The
technical solution had to meet all the requirements for an accurate, auditable, enforceable system
suitable for rapid nationwide implementation and an initial volume of 400,000 commercial vehicles of
over 3,5 tonnes in weight. Charging was meant to reflect the real costs to the roads and to the
environment.
In line with Austria’s transport policy and European objectives, key issues of interoperability and nondiscrimination of users were also critical elements within the tender.
The fully electronic lorry tolling system was implemented on the entire Austrian highway network. The
system is in a Multi Lane configuration which allows tolling to occur while vehicles are travelling,
creating unimpeded driving conditions. This Multi Lane Free Flow system is characterized by gantries
placed above the highway lanes, using 5.8 Ghz microwave DSRC transceivers mounted on the gantries
to communicate with OBUs installed on the windscreen of passing lorries. Changing lanes while
passing beneath the gantries does not influence the tolling transaction.
In the Austrian system, road users are charged according to distance travelled and the number of
axles of their vehicle. To ensure that the charge is correct, the declaration of vehicle classification,
depending on the number of axles, needs to be verified. Any anomalies need to be recorded
accurately and fines collected from the road user based on secure, legally admissible evidence.
Enforcement is therefore a key part of the system concept.
Regarding enforcement, the Austrian tolling system is comprised of three elements:

Stationary enforcement: a percentage of the existent toll segments are equipped with
stationary enforcement systems able to classify passing vehicles and capture their license
plates and picture so the vehicle may be traced and payment enforced.

Portable enforcement: to allow a temporary upgrade of road side equipment to include vehicle
detection, classification and enforcement capabilities.

Mobile enforcement: specially equipped vehicles are completely outfitted as mobile
enforcement offices, including DSRC microwave antennas, hand held terminals and printers.
There were at least three innovative aspects to the Austrian system:
1. it was the first time in Europe that OBUs were mandatory
2. it was the first large-scale MLFF system in Europe
3. it was the first time that 'charging-only' gantries were used in Europe - previously all
DSRC charge sites included enforcement
Main conclusions:
The GO system introduced several innovations to HGV road tolling that are still a reference for many
major systems, like TIS-PL, LSVA or MYTO-CZ. Current projects are starting to consider other
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
20 of 151
technological solutions, such as GNSS due to the maturing of the technology and the benefits it
provides when compared to DSRC.
4.1.1.2.5. Slovakia [RD.6]
Slovakia is implementing a HGV tolling system based on GNSS technology nationwide due to go live
on January 1st 2010. The toll charge is calculated by the vehicle class, number of axles, total weight,
distance travelled and possible time classification (6:00 – 20:00 and 20:00 – 6:00).
The core element of the toll system is an OBU designed for automatic toll collection equipped with
satellite localisation service (GPS), mobile communication device and a 5.8 Ghz DSRC module. The
OBU uses the GPS signal to determine whether the vehicle is travelling on a toll-free road or toll route
segment.
The calculated toll charge is transmitted to the central system and converted into payment data and
an invoice is generated.
The central system allows to collect, process, use and store:

Evidence licence plate data and its photographic image;

Technical data of the vehicle;

Identification code of OBU;

Length of the travelled journey;

Fee tariff and calculated sum;

Data on vehicle operator.
Main conclusions:
By adopting GNSS as the technological solution, countries like Slovakia, Slovenia and Sweden are
showing an increased trust in the technology results. This shows a clear trend in the adoption of GNSS
as the reference technology for future road tolling systems.
4.1.1.2.6. TIS-PL (France)
The TIS-PL project was initiated by the French motorway concessionaires in order to implement an
interoperable system dedicated to heavy goods vehicles (HGV), based on the LIBER-T system. The
TIS-PL principles are closely related to the Cesare II key rules and conform to the Cesare III model.
In practice, interoperability has only been achieved within France, although some initiatives like PISTA
(Pilot on Interoperable Systems for Tolling Applications) did lead to a small progress to have
interoperability with Spain, Austria and Slovenia.
The interoperable EFC service offered to the Users can be defined with the following items:

A single OBU which can be used as a mean for the payment of tolls in the EFC lanes of the
TIS-PL concessionaires, using DSRC technology;

A single contract for the TIS-PL service, signed with an agreed Issuer (the agreement is
delivered to the Issuer after verifying his financial and technical ability to operate as a TIS-PL
Issuer);

A single invoicing process for
concessionaires charging the toll.
several
motorway
services
having
different
TIS-PL
At the moment, the domain of the TIS-PL service is national. However, it is not limited to France
provided that all rights and duties coming within the Contractual Joint Venture agreement between
concessionaires are fully accepted.
Main conclusions:
The TIS-PL system results are closely related with LIBER-T results since both systems are very similar,
and they show that DSRC is still a very good, cost-efficient option for highway tolling, both for private
vehicles and HGV.
One of the major drawbacks of TIS-PL is it’s inadequacy to toll HGVs outside highways, since DSRC
costs become too high when applied to high complexity road networks.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
21 of 151
4.1.1.2.7. Slovenia
The Slovenian government decided to introduce a traffic free flow electronic-toll system for heavy
vehicles (above 3.5 t) based on GNSS technology on 2000 km of motorways, expressways and
national roads. For that purpose, a tender is expected in 2009/2010.
Until the full implementation of this system, all vehicles are taxed by a vignette system. This vignette
system was introduced on July 2008 and is currently under great discussion due to its tariff
limitations, where occasional travellers/tourists are demanded to buy a vignette for at least a 6 month
period. This is also becoming a problem for truck fleets operators that have to find alternative routes
to avoid paying the extra price.
All HGVs must be equipped with an OBU with satellite technology that registers kilometres travelled.
This OBU may be connected to the vehicle tachograph for better accuracy. The main goals of the
system are:

Increased traffic flow on toll roads;

Reduced gas emissions;

To enable an upgrade of services such as payment of a parking fee, payment of environmental
tax when driving in a national park or SOS calls in case of accidents.
Main conclusions:
The Slovenian approach is much inline with the Slovakian and the Sweden solutions, therefore
presenting similar objectives. By adopting GNSS as the technological solution, countries like Slovakia,
Slovenia and Sweden are showing an increased trust in the technology results. This shows a clear
trend in the adoption of GNSS as the reference technology for future road tolling systems
4.1.1.2.8. ARENA (Sweden)
Sweden intends to implement an HGV tolling system (ARENA) by 2011, based on GNSS technology.
Tolling fees will be calculated on a distance base.
Currently, ARENA is in its trials phase.
The main goals for the Swedish government are:

Achieve an environmentally friendlier vehicle fleet;

Increase the efficiency of HGV use and load factor;

Fairer conditions for competition between domestic and foreign hauliers;

Possibility to route traffic to roads where it is lest disruptive;

In the long term: create better conditions for increasing the proportion of rail and sea
transport.
The ARENA concept is being developed with functional and market-based approach. No technical
solutions are defined, allowing it to be implemented in several ways, assuming a multi-provider
model. It is based on the following principles:

The toll charger (government) sets rates and conditions;

The tax will be differentiated according to vehicle properties (weight and environmental class)
with further differentiation a possibility;

Vehicles subject to kilometre tax have specific vehicle equipment for this purpose (OBU);

Use of an OBU is mandatory, but the system must offer an emergency solution in case the
OBU stops working;

The toll charger controls the toll service providers via technical, performance and security
specifications.
Main conclusions:
The ARENA approach is much inline with the Slovakian and the Slovenian solutions, therefore
presenting similar objectives. By adopting GNSS as the technological solution, countries like Slovakia,
Slovenia and Sweden are showing an increased trust in the technology results. This shows a clear
trend in the adoption of GNSS as the reference technology for future road tolling systems
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
22 of 151
4.1.1.3. Urban Charging
This chapter presents some implemented European initiatives regarding urban congestion charging:
Title
Technology
London Congestion
Charge
ANPR
United Kingdom
Country
2003
Year
Stockholm Congestion
Charging System
ANPR
Sweden
2006
Ecopass
ANPR
Italy
2008
Oslo Toll Ring
Toll Booth
Norway
1990
Link
www.cclondon.com
www.comune.milano.it/dseserver/ecopass/servizi.html
Table 4-3 – urban tolling initiatives
4.1.1.3.1. London Congestion Charge (United Kingdom)
Congestion charging is a way of ensuring that those using valuable and congested road space make a
financial contribution. It encourages the use of other modes of transport and is also intended to
ensure that, for those who have to use the roads, journey times are quicker and more reliable.
The London Congestion Charging system of central London relies on the use of an intricate system of
cameras and manned patrols to enforce the charging of a toll after a user has entered the applicable
zone.
Figure 4-3 - Current London Congestion Charging zone
A network of over 340 camera sites containing over 1000 cameras, colour and monochrome, enforce
and monitor the vehicles entering and exiting the charge zone. Every vehicle is photographed and has
its license plate number identified and recorded using Automatic Number Plate Recognition (ANPR)
software. At the end of the day those who have not paid the required fee will be issued a notice of
penalty (sent to the registered owner of the vehicle in question), following a completely manual
reading of all non-paying vehicle plate photos to avoid error.
Traffic signs make it very clear when drivers are approaching, entering, and leaving the congestion
charging zone. Advance information is provided on the main approach roads using two types of sign.
At a short distance from the charging zone signs indicate the charge and the hours of operation.
On the approaches to the congestion charging zone, directional signs indicate which routes take
drivers into the charging zone and which roads do not. As drivers enter the zone signs indicate the
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
23 of 151
boundary of the zone and the hours of operation of congestion charging. These are accompanied by a
red symbol in each lane of traffic at the entry points to the charging zone. Some approach lanes to the
charging zone are also marked with a white symbol.
As drivers leave the congestion charging zone signs indicate the end of the zone.
Main conclusions:
The London Congestion Charge is used to prevent higher levels of congestion on already congestioned
and polluted areas in London. ANPR is used mainly for enforcement purposes and is a proven solution
for this type of application, but the future trend could be in hybrid systems, possibly ANPR+DSRC as
the congestion charging technology trials showed (see section 4.1.2.1).
4.1.1.3.2. Stockholm Congestion Charging System (Sweden)
The Stockholm congestion charging system went live Jan 3rd 2006, being the third dedicated urban
congestion charging system in the world (after Singapore and London). There was an initial trial and it
is now working as a fully operational system. The system consists of a cordon around the city centre,
with a time-varying charge being levied for each crossing in any direction. The charged area covers
around 41 sq.km. The charge is levied 6:30-18:30, and varies between 10 and 20 SEK. The
Stockholm system consists, apart from the charging scheme, of a large investment in buses from the
suburbs to the inner city. The usage payment is based on video (ANPR) from front and rear linked to
the vehicle register.
Main conclusions:
In parallel to the charging system introduction, Sweden also introduced enhancements to the public
transport network. By doing so they showed concerns on really improving traffic and environmental
conditions in Stockholm, one aspect that may have contributed to reduced social concerns regarding
the system.
In the technological field, this Sweden system is making use of ANPR as a core technology for
congestion charging.
4.1.1.3.3. Ecopass (Italy)
The Ecopass program is a traffic pollution charge implemented in Milan, Italy, as an urban toll for
some motorists travelling within a designated traffic restricted zone. The Ecopass was implemented as
a one-year trial program on January 2008 and later extended until December 2009. A public
consultation was planned to be conducted early in 2009 to decide if the charge becomes permanent.
The primary purpose of program is to reduce traffic and air pollution, it is based on a fee structure
according to the vehicle's engine emission standards and to use the funds raised through the charge
to finance public transportation projects, cycle paths and green vehicles.
The amount of the charge depends on the vehicle's engine emissions standard, and fees vary from € 2
to €10 on weekdays from 7:30 a.m. to 7:30 p.m. The Ecopass fee can be paid before entering the
restricted zone or up to midnight the next day after entering. There are daily and multiple-day passes.
Payment of the fee can be made via internet, by telephone, in designated banks or by direct debit to
the user's bank account, by first an Ecopass card must be issue at designated places.
Main conclusions:
The Ecopass adoption of ANPR as the technological solution shows that this technology is still viable
for urban charging. But this scenario might not be true for much longer as other systems are planning
on upgrading to different technologies, showed by the London Congestion Charging Technology Trials
where DSRC was proven adequate for urban charging and could even be implemented to be
interoperable with the current ANPR system.
4.1.1.3.4. Oslo Toll Ring (Norway)
The Oslo Toll Ring was set up in 1990 in order to:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
24 of 151

Fund essential repairs and investment in Oslo’s road network - to increase road capacity as
the existing system was causing delays.

Fund greater investment in public transport schemes.

Combat local environmental problems.
This Toll ring is a toll financing system, planned to be a temporary way of funding transport
investment. It was not designed as a method of reducing congestion within Oslo.
The toll ring was set up around Oslo; any vehicle travelling into Oslo must pass through a toll booth
and pay a fixed rate. This can be paid in cash, using a credit, debit card, or more quickly using the
smart card scheme that was set up. About 80% daily tolls are paid using a smart card, which means
that there is relatively little congestion caused at the 19 toll plazas.
The use of toll booths like this means that all vehicles entering have to pay, there is no way to avoid it
as all roads in are tolled, and even those who do not travel to Oslo regularly pay when they enter the
city.
As the scheme is a method of generating revenue, as opposed to an attempt to combat congestion,
there is no peak charging on the toll ring, even though the charge is in 24 hour operation. This is
because the system is not attempting to use price elasticity to encourage people to travel into Oslo at
different, less busy time, but as a method of getting the money for investment schemes.
Main conclusions:
The Oslo scheme has been successful at raising revenue for investment in the road and public
transport systems, leading to improvements in the quality of both services. The effect of removing
some traffic from the roads, particularly from the city centre, has also had external benefits such as a
reduction in congestion and accidents. However, the scheme has been politically unpopular and the
future of the scheme is currently under debate.
Furthermore, the technology used is completely outdated. Other technologies are less costly to
implement and provide more advantages, like ANPR or DSRC.
4.1.1.4. The Dutch System
As a result of the three previous described types of projects, it is presented the ABvM project, which
has the major purpose of developing a common solution to all type of vehicles driving in any type of
road at a national scale. The ABvM project will be used as guideline in GINA project.
4.1.1.4.1. ABvM
The Dutch State is currently working on the “Kilometre Price” Act (KMP Act) [RD.19]. The purpose of
this Act is to introduce a price per kilometre for Motor Vehicles in the Netherlands.
With this measure the Dutch government intends to phase-out the current Dutch automobile tax
(BPM), implementing a road pricing method that charges the user according to his own road usage.
This measure also intends to invite the population to increase the usage of public transportation,
deterring the usage of personal vehicles. The reduction of traffic contributes to the reduction of
pollutant emissions, consequently a greener environment. Since the user will only pay his road usage,
instead of the current BPM taxes, this measure also tends to be a social fairer taxing schema.
The starting point for the requirement specification [RD.17][RD.18] is an electronic road pricing
system with a charge per distance travelled, based upon time, location and vehicle characteristics. A
road pricing system with these characteristics is described in report ‘Nationaal Platform Anders Betalen
voor Mobiliteit’ as ‘variant 5’. The implicit requirements of variant 5 are transformed into more explicit
requirements to further analyse the cost driving factors of this policy option and explore alternative
solutions to reduce the total costs of the system.
Main problematic areas are identified and possible solutions for these problems are recommended.
The main part of the study focuses on the analysis of a large GPS data set. Unique characteristics of
this data set are:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:




D2.1
15/09/2009
2.0
25 of 151
The data originate from vehicles that were used for normal day-by-day trips,
The vehicles drove in the Dutch environment (cities, rural areas, motorways) distributed over
a large part of The Netherlands,
It is detailed and extensive,
Both the GPS-positions and the distance travelled, as calculated from the in-car CAN-bus
(based on wheel revolutions), are logged and can be compared.
In order to define the ABvM requirements the following topics were considered:
 System Functionality;
 Users;
 Technological Requirements;
 Costs;
 Implementation;
 Security and Privacy.
The implementation of ABvM is intended to be phased during the next years until it’s completion in
2016-2018.
One of the reasons leading to this phasing period is that, beyond the introduction of technology, there
is also the human factor to be taken into account, meaning that people and businesses must have
time to gradually adapt to a new way of paying for mobility. Governments and road administrators
must also incorporate ABvM into their mobility policies.
There are two options in consideration for the implementation of ABvM:

Achieve a market for multiple certified service providers - Meaning that entities like insurance
companies, car leasing companies, motorway operators or even governments must agree to a
set of standards and policies that will allow them to use the same road pricing scheme
anywhere, by adopting the same charging methods and policies, the same technologies (it
makes no sense for the final users to have to install more than one type of OBU in their
vehicles);

Create a dedicated back office operating under public governance, combined with certified
vehicle equipment. This option should only be adopted if the first one does not succeed.
One important note is that enforcement and supervision must always be kept under public
governance.
The main implementation tracks for ABvM are:

Preparation and rollout in terms of tax restructuring;

Preparation and rollout in terms of technical system for road pricing;

Developing the road pricing legislation;

Preparation and rollout in terms of communication to road users closer to the time that the
road pricing system will begin to function.
Implementation will be divided into 4 stages according to its timeline:


2008-2010 – Mobility projects and making road pricing concrete.
o
2009 – Implementation decision on the road pricing law and begin of broad public
communication;
o
2010 – Decision on new provincial tax area, instead of provincial surcharges;
2011 – Rollout of the first part of the system, consisting on the introduction of road pricing for
goods transport;
o

GINA
Implementation after completion of large-scale volume tests, considering the quality of
the system in relation to the basic condition that the operating cost at the time the
system is fully operational will be no more than 5% of the total road pricing revenue;
2012-2016 – Rollout of the entire system, consisting on:
o
2011 – Introduction of the first group of passenger cars and delivery vehicles;
o
2016 – Entire system operational;
o
2016 – Delivery decision after complete rollout of the technical system to all road
users;
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:

D2.1
15/09/2009
2.0
26 of 151
2016-2018 – Completion of the road pricing system;
o
2018 – Completion of current Dutch automobile tax (BPM) phase-out.
The BPM tax will be phased-out between 2011 and 2018, and will be replaced for the rate for
kilometre which in turn will replace all fixed car taxes and will have an optimal effect in terms of
improving accessibility and environment.
4.1.1.5. RUC Initiatives Summary
The current chapter presented several initiatives related to road user charging, from which three main
types are evidenced: Motorway tolling, Heavy vehicles tolling and urban tolling.
Since each type of tolling has different characteristics, the technology adopted for each case also
needs to include different features.
As a result it can be concluded that DSRC is the technology currently being used for exclusive
motorway tolling, independent of the type of vehicle. This trend doesn’t seem to be changing in the
near future. Portugal is an example of a country adopting DSRC MLFF as the technological solution for
nationwide motorway tolling for all types of vehicles in the near future (end of 2009). The justification
for this decision is that there is no regulation for nationwide road tolling and therefore only highways
and bridges may be charged in Portugal.
For urban tolling, ANPR is currently the most widely adopted technology, usually by building a “ring”
around the urban area of interest. This allows tolling all vehicles, independent of their class. Oslo still
has a toll booth based solution, but it is no longer viable to adopt such a solution due to the
technology advances in other areas (ANPR, GNSS).
For heavy vehicles, there is a mix of DSRC and GNSS solutions currently implemented. The main goal
here is to tax a specific type of vehicle on a country-size region. For this purpose alone, DSRC seams
to be the best solution, but the current trend is to adopt GNSS since it’s flexibility will allow to toll not
only HGVs but also other types of vehicles on a country-size region, independent of the number or
complexity of the road network. This trend can be seen on the newest initiatives that possibly took
into consideration the success of systems like Toll Collect and the maturing and advantages of the
technology evidenced by projects like the ones described in the next chapter. Example initiatives are
being implemented in Slovakia, Slovenia or Sweden. The main objective for all the examples is to
charge HGVs on different types of roads, not only highways. Another important example is the Czeck
MYTO-CZ system, which is currently DSRC only, but pilot tests have already taken place to expand it
to interoperate with a GNSS solution, allowing to charge HGVs on more road types.
4.1.2. OVERVIEW OF R&D ROAD USER CHARGING EUROPEAN INITIATIVES
RELEVANT TO GINA
This chapter presents some European R&D projects that contributed to the feasibility and maturity
analysis of nowadays technology, when applied to road user charging:
Title
Entity
Start
Year
Congestion
charging
technology
trials
Tfl
ARMAS
ESA
2006
GIROADS
GSA
VeRT
GSA
GINA
End
Year
Description
Conclusions
Link
Technology comparison
when applied to urban
charging schemes
DSRC proven to be the best
choice to integrate with the
existent ANPR system
www.tfl.gov.uk
2009
GNSS technology
feasibility
demonstration for the
road sector
ARMAS has proven feasible to
apply GNSS-based technology in
the road sector
armasiii.skysoft.pt
2005
2007
Relevance of Galileo to
the road sector
Key to reduce negative impact of
the road sector.
Offers new services and business
opportunities
ec.europa.eu/transport/gsa
/rd/rdgiroads.html
2003
2005
Demonstrate GNSS
GPS+EGNOS not accurate enough
www.vert-project.com
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Title
Entity
Start
Year
End
Year
Description
advantages
Conclusions
D2.1
15/09/2009
2.0
27 of 151
Link
for urban environments. Galileo
expected to increase availability
and reduce urban canyon effects
CURACAO
EC
2006
2007
Coordinate R&D and
monitor results of RUC
implementation in
urban areas
CESARE I to
IV
ASECAP
2007
2009
Specify, design,
develop, promote and
implement a common
interoperable EFC
system
Interoperability objectives can
become reality if cooperation
between public and private
sectors is assured
www.asecap.com/english/p
rojets-cesare4-en.html
RCI
EC
2005
2008
Demonstrate how RCI
interoperable
prototypes adapt
functional behaviour
when crossing borders
Operational interoperability can
be realised on the basis of clear
agreements between
stakeholders
www.ertico.com/en/subproj
ects/rci/home
MISTER
CEN
2004
Initiative to add
technical and
procedural
requirements for ISO
17575
Superseded when the structure of
ISO 17575 was revised and RCI
results were published
U-OBU
GD TREN
2005
Define and access the
benefits of a universal
OBU
Possible to create UBOU with 5
key services, realised with
current mature technologies
2006
www.curacaoproject.eu
Table 4-4 – R&D RUC initiatives
4.1.2.1. Congestion charging technology trials (TfL) [RD.8][RD.9]
In 2003, Transport for London (TfL) started the congestion charging technology trials aimed at the
investigation of different technologies available which may:

Give more flexibility for paying the charge,

Allow for new charging approaches (policies),

Reduce the scheme’s costs
The main goal was to identify technologies which could be deployed between 2005 and 2015.
The trials were divided into 3 stages. Stage 1 was completed in late 2004 and performed proof of
concept tests of a long list of technologies, trialled and identified technologies and technical design
issues to be investigated further. Stage 2 ended in July 2006 and focused on further testing the
previously selected technologies on a wider scale. Stage 3 was completed on July 2008 and was
focused on usability, aesthetics, operational issues and interoperability aspects of the tested solutions.
The main technologies taken into consideration were ANPR, DSRC, GPS and Mobile telephony.
GPS
The first stage demonstrated that GPS devices showed an average error of 15m with a rare maximum
of up to 1km. The error results depended highly on the location, and were affected by urban canyons
– a common problem in an urban environment. It was determined that a buffer zone of 57m on
average would be required for the system to be 99% confident for the “average” devices, and 93m on
average for the worst performing devices. For zones affected by the urban canyon effect, the buffer
zone would need to be extended to about 250m for the average devices.
Stage 2 tested GPS with enhanced technology such as combinations with location data from 3G
networks, correction techniques such as Kalman filtering and various map-matching techniques.
A Kalman filter interprets a given position estimate reported by the GPS unit in the light of previous
estimates.
These initial trials concluded that GPS is not sufficiently accurate on its own to allow a road user
charging system to rely on the accuracy of any individual reported point. But virtual gantries
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
28 of 151
appear to be adequate. Virtual gantries have the advantage that no roadside infrastructure is needed
and their configuration is very flexible, but OBUs need to be installed on all national vehicles, just to
charge for the London Congestion charge zone. This indicates that GPS is more appropriate for a fully
fledged nationwide charging system, since the cost to implement it in a single region would be
practically the same as implementing it nationwide.
Distance-Based Charging
Following the trials of GPS OBUs reporting individual positions, TfL also ran a series of trials looking at
a complete distance-based charging (DBC) system. The trial researched not only the performance of
the OBUs, but also of the back office systems necessary to produce a charge for a journey. The trials
involved test drives totalling more than 14,000 km in central London and were carried out for 14
different vendors with 17 different systems, plus a common reference device.
Results were
considered at

the location level (the accuracy of OBUs for individually reported positons)

the road segment level (the accuracy of identifying road segments used) and

the charging level (the accuracy of reported journey length and the total charge applied).
At the location level, the best performing system had an average location error of 5.1 metres. The
average for all equipment was 6.7 metres with only one device having an average error of greater
than 8 metres. This was a significant improvement on previous trials referred to above.
The best-performing system at the road segment level (map matching) correctly identified 98.6% of
segments by length, with a further 1.0% of segments being incorrectly identified as part of the
journey. Where vendors had their own map matching systems (i.e. 9 out of 14), the average for all
equipment was 96.8% of road segments correctly identified.
Based upon a purely hypothetical charging scheme, the best-performing DBC system at the overall
charging level had an average billing error of 0.86% and a magnitude of journey length error of
0.82%. However, there was a wide range of performances. The average errors for all vendor
systems, using their own map-matching systems, were 6.7% (billing error) and 5.4% (journey length
error). The sample interval of the OBU and the performance of the map-matching algorithm were
found to be the most important factors affecting overall system performance. The integrity of the
current GPS was found to be too low for it, alone, to be currently used to determine a vehicle’s route
in central London. Other inputs from, for example, the odometer or a Controller Area Network (CAN)
bus can improve overall performances.
As well as the controlled trials, where trials vehicles were driven on known, accurately surveyed routes
under controlled conditions, OBUs were fitted in 530 volunteer vehicles which drove around the
London Congestion Charging zone in their normal fashion, allowing notional bills to be produced based
on the same, purely hypothetical charging scheme. A sample “bill” is illustrated in the figure below.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
29 of 151
Figure 4-4 – Account from TfL's DBC Trials
The first part of these volunteer trials was an accreditation phase where the accuracy of vendors’
systems was measured at the journey level in order to select the best six vendors to be used in the
main part of the trials.
Vendors were asked to use standard equipment, rather than any “best-ofbreed” equipment not readily available which may have been used in the previous stage. The
accuracy of the systems varied for the tested vendors with 85% to 80% of all recordings being
between -5% and +10% of the true journey distance. None of the vendors achieved the accuracy of
the best results referred to above, where the best vendors achieved an accuracy of +/- 1%. This
could suggest that real-life operational systems are not in practice as accurate as pilot systems
suggest; it could also be that since this study encompassed a wider area than the previous stage, that
the areas of London driven in for this study were inherently more difficult to achieve accuracy in.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
30 of 151
The trial concluded that the best-performing systems might meet charging accuracy requirements.
They compare well with the performance accuracy quoted for truck tachometers and London taxis at
approximately ± 4%. However, the lower accuracy of the volunteer trials raises questions about the
achievability of this best performance and the wide range of system performance points to potential
difficulties in certification and procurement. A distance-based charging scheme with current GPS
technology would need significant safeguards to ensure that customers were not over-charged.
DSRC and ANPR
Stage 1 demonstrated that it was feasible to implement an Urban Charge Point (UCP) comprising a
DSRC microwave beacon and ANPR camera equipment mounted on a pole and outrigger. The
performance results were above 99.5% DSRC tag detection rate, and ANPR provided an additional
evidential record to back up the record of a tag transaction.
The concept of a UCP was further developed in stage 2 by mounting the DSRC and ANPR systems on a
single pole and integrating them at the road side and ensuring that a series of UCPs would work
together to provide an overall system solution.
Mobile telephony
For these trials, both GSM and 3G technologies were taken into account by using commercial
handsets. The first approach was to identify the cell with which the handset communicated. The
second approach was to query the network LBS (Location Based Services) for location based
information.
For stage 1 trials, LBS accuracy was on average of 2.3 Km, and the conclusion was that LBS would not
be suitable due to its poor accuracy. Another problem was that the position results were delivered
hours after the request was made. This is a problem in the case of real-time positioning is needed.
Stage 2 trials focused on the usage of “pico-cells”. These cells have a range much smaller than normal
cells (10s of metres versus 100s of metres or even kilometres) and would be placed across the
boundaries of tolled zones. The trial showed that given the correct radio frequency (RF) engineering at
the cell site, a reliable detection rate of 93% could be achieved.
The problem is that this kind of RF engineering is complex and site specific. Depending on the site
layout and the RF engineering, the footprint of the detection area fluctuates to a certain degree,
enabling the capture of handsets outside the tolling zone. Moreover, the handset needed to be in idle
mode permanently to guarantee the detection rate. This means that a dedicated device would be
needed, removing the advantage of mobile phones.
Since another device (or tag) was required, the mobile telephony approach brings no added value
compared to the DSRC approach.
Stage 3 trials
Stage 3 focused on the development of the UCP concept by different suppliers and its testing on the
Congestion Charging Zone.
Several tests were undertaken by using different types of vehicles and different situations were taken
into account, like distance to other vehicles, passing by the UCP undercover by other vehicles,
different driving styles, direction detection, U-turns, edge tests, etc.
The trials concluded that 99.9% of the vehicles were detected by one of both of the ANPR and DSRC
sub-systems, being ANPR performance slightly lower, but well above 99%. On average, ANPR
demonstrated a performance of 95% and varied from 82% to 99.8% depending on the site.
Spatial matching performance was measured at 99.1% by checking the detections where both a DSRC
transaction and a correct ANPR read were available.
The edge tests were designed to determine the impact in performance due to drivers trying to evade
detection by driving at the extremities of the carriage way. The results showed a reduction in
performance of 1.9% for DSRC and 2.8% for ANPR.
Main conclusions:
Taking into account the results of stages 1 and 2, stage 3 focused on the DSRC approach. The final
trials demonstrated that the performance of UCPs in live systems was slightly better than the one
found in stages 1 and 2, with a DSRC detection rate of 99.7%, UPC detection rate of 99.9% and a
spatial matching accuracy of between 98.5% and 99.1%.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
31 of 151
It was also demonstrated that a DSRC solution from a different supplier could be integrated with the
already existent ANPR system by combining a specific focal length of camera lens with a specific aim
point. With this integration, there is no necessity to replace any existent cameras in the case of DSRC
introduction.
GPS was considered not sufficiently accurate to allow for a road charging system to rely on the
accuracy of any reported point. However, GPS combined with map-matching could be the basis for
distance-based charging.
The problem of “urban canyons” still needs to be addressed, since even the best systems tested
presented significant errors in parts of London affect by this problem.
The introduction of Galileo was referred as capable of reducing this problem but not eliminating it, and
OBU technology is also expected to be mature by the time Galileo becomes fully operational.
Distance based charging was considered already mature, but there are still logistical, operational,
enforcement and political issues to be resolved before the introduction of Distance based charging.
4.1.2.2. ARMAS (ESA)
European Space Agency’s (ESA) project “Active Road Management Assisted by Satellite” (ARMAS)
aims at transforming the transport infrastructure (roads, bridges, tunnels …) into safer and more
customer-friendly environments, by:

Improving Safety;

Increasing Dynamic Traffic Management capabilities;

Providing Electronic Fee Collection mechanisms;
The project is divided in several phases. The ultimate objective of the “ARMAS” Phase I project
(performed between March and December 2003) was to assess the feasibility of such a system
(including issues like legal and institutional aspects), based in Global Navigation Satellite Systems
(GNSS) – especially EGNOS - and Cellular network (CN) technologies – GSM and GPRS.
The Phase II of the “ARMAS” project (executed between March 2004 and December 2005) main goals
were:

Implement an
applications;
“ARMAS”
Test-bed
for
advanced
Intelligent
Transport
Systems
(ITS)

To investigate the critical issues related to a successful introduction of Virtual Tolling using the
above Test-bed, focusing on topics like reliability, integrity and fraud robustness.
The above mentioned goals were translated in the implementation and demonstration of the following
functionalities:

Electronic Fee Collection based on Satellite Positioning (also known as “Virtual Tolling”),
contemplating various road pricing models (Gatekeeper, Corridor Pricing/Passage Tolling,
Congestion Zones/Cordon Pricing, Distance Based Pricing, Combination);

Warnings Provision: provision of information about hazards ahead in the road to the driver of a
vehicle, in order to increase the time-to-act;

SOS Request: ability to request (and receive acknowledge) assistance upon an emergency;
Currently the “ARMAS” project has finished the third phase of work. The “ARMAS” project has the
objective of demonstrating the feasibility of satellite based technologies in car navigation devices for
improving road safety, use in dynamic traffic management and providing a means for generalized and
cost-effective road pricing.
The following picture presents the “ARMAS” architecture, where the two main components are:

GINA
In-Car System (ICS): Traditionally known as On-Board Unit (OBU), it’s the set of devices that
reside inside the car. In “ARMAS” GPS, EGNOS Signal-in-Space (SiS), EGNOS over GPRS,
DSRC, GSM Voice, GSM Data, GPRS, Inertial Sensors, Map Matching and RAIM (Receiver
Autonomous Integrity Monitoring) were used;
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:

D2.1
15/09/2009
2.0
32 of 151
“ARMAS” Fixed-Part (AFP) or Central System (CS): Set of devices/systems that resides outside
the car. Main technologies: GPS, EGNOS SiS, EGNOS over GPRS, DSRC, GSM Voice, GSM
Data, GPRS and Map Matching.
Figure 4-5 – “ARMAS” overall architecture
The different road user charging schemes (distance based, segment based, zone based, time-based…)
all rely on identifying correctly that the vehicle is using the defined “infrastructure”. This is achieved
by defining different geographical objects (“charge objects” or “geo-objects”):

Cordon;

Virtual Gantry;

Segment;
GP
4
GP
5
GP
1
GP
0
GP
2
GP
3
Figure 4-6 – “Charge objects” or “Geo-objects” in GNSS-based EFC systems
Electronic Fee Collection/Road User Charging technology today is mainly based in the use of DSRC
(“Dedicated Short Range Communications”). Currently in Europe, only a couple of operational systems
use GNSS for Electronic Fee Collection/Road User Charging (TollCollect being probably the best
known…).
GNSS has several major advantages with respect to DSRC, namely the flexibility in setting up and
change the tolling schemes and the ability to easily provide value added services.
Main conclusions:
The ARMAS project focused on proving the technological feasibility of GNSS for the road sector and
the project conclusions focused on GNSS performance and technology applications, such as PAYD,
dangerous goods transportation, children and youth transportation, traffic management and RUC.
Specifically on RUC, ARMAS showed that signal integrity will provide a legal standpoint for taxation
purposes, and the introduction of a second GNSS system (Galileo) will provide better accuracy, thus
providing a better taxation scenario.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
33 of 151
4.1.2.3. GIROADS (GSA) [RD.13]
GNSS Introduction in the ROAD Sector (GIROADS) has focused in the achievement of a shared
understanding of the relevance of GNSS, and EGNOS in particular, to the road sector.
GIROADS was a 24-month project commissioned by the European GNSS Supervisory Authority with
funds from the EC 6th Framework Programme for Research and Technology Development with the
purpose of aggregating the road community’s proposals to facilitate the technical and commercial
introduction of Europe’s satellite navigation programme to the road transport sector.
The main drivers to this project were the current road transport situation and how EGNOS and Galileo
could contribute to reduce its negative impact. There was a special concern in answering to the
following challenges:

Achievement of a significant and lasting decrease in road accidents and deaths;

Identification of stable mechanisms of funding for road improvement;

Eradication of bottlenecks and curbing of pollution.
GIROADS has mainly capitalized on differentiators of EGNOS/Galileo such as integrity in order to
accomplish the work proposed at the beginning of the project.
The project faced other challenges such as the fostering and demonstration of the concept of
utilization of a unique OBU for different services, from several perspectives, including technical and
commercial, taking into account the existing regulatory framework and related standardization
process. Another challenge was also to demonstrate different possibilities for value added services to
be considered in the bundle.
The GIROADS project activities were organized in 2 phases:

Phase A – where a high level analysis of the road sector was accomplished;

Phase B – where a detailed implementation of relevant trials was made.
The basic approach for the GIROADS infrastructure was to develop a common “horizontal” platform
that was able to provide support to all planned services together with specific “Service Centers”. These
Services Centers are application-specific and connected to the mentioned common platform.
Figure 4-7 – GIROADS High Level Architecture
The major components identified in the GIROADS architecture are:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
34 of 151

The Mobile User Equipment.

Multi-Service Front-End – a sort of Personal Digital Assistant (PDA) that as the role of showing
to the users all the information (routes, traffic info, billing,…) provided by the Multi-Services
Gateway.

The Service Providers.
The GIROADS prototype was exercised by a series of demonstrations running between September
2007 and mid November 2007.
Demonstration 1: Electronic Fee Collection
Demonstrated the added value of EGNOS/Galileo for road charging in 2 different scenarios: urban and
highways.
Demonstration 2: Pay-per-use Insurance
Demonstrated the possibility to generate a map of the driver’s risk when driving (user risk profile) by
using GNSS technology.
Demonstration 3: Traffic Information Generation (using Floating Car Data) and Provision
Demonstrated the use of GNSS for the collection of traffic information and the generation of reliable
real-time congestion information.
Demonstration 4: Livestock transportation
Demonstrated the tracking and tracing of livestock transported in a truck in journeys.
Demonstration 5: Urban Fleet Monitoring
Demonstrated the use of EGNOS tracking and tracing services for regulated fleet management in
urban areas and to demonstrate and promote the benefit of EGNOS for urban mobility operations.
Main Conclusions:
The main outcome of the GIROADS project was the demonstration of the relevance of Europe’s
satellite navigation programme to everyday needs of the road transport sector. GIROADS allowed
concluding that EGNOS / Galileo can be key to reduce the negative impact of road transport and offer
new services and business opportunities.
GINA uses the results from projects like GIROADS and ARMAS as a starting point. While ARMAS
focused mainly on the technology feasibility and GIROADS focused on the positive impacts, services
and business opportunities of the introduction of EGNOS / Galileo in the road sector, GINA intends on
addressing the extensive adoption of EGNOS / Galileo in the road sector. The project will explore 3
main aspects:

Technical feasibility on a large scale;

Economic feasibility and business potential for the applications;

Positive impacts on issues such as congestion and pollution.
While ARMAS and GIROADS analysed specific aspects and trialled the technology as a proof-ofconcept, GINA will address the analysis of the feasibility of EGNOS / Galileo for the road applications
by implementing a large-scale, fully functional demonstrator of GNSS-based RUC and VAS at national
level, supporting the Dutch ABvM requirements. Different VAS will be demonstrated to show the
flexibility and business potential of GNSS in the road sector.
4.1.2.4. VeRT (GSA) [RD.16]
The scope of VeRT project was to demonstrate the feasibility of EGNOS/GALILEO on the road
applications that can profit from the use of the new European Satellite localization system by
demonstrating its competitive advantages: increased accuracy, availability, integrity and certified
services. It also wanted to demonstrate the improved performance of EGNOS, as compared to GPS
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
35 of 151
based positioning, used with other emerging technologies including mobile communications, satellite
communications and geo-information.
VeRT project covered the first steps for the implementation of the end-to-end Road Services based on
new Satellite Navigation Technologies (Now EGNOS, Galileo in the future):

The Definition of Service Concept for the Road Domain which take advantage of the use of
EGNOS and Galileo, i.e. not feasible by using current navigation solutions;

The identification of User Needs, followed by the definition of the Service Requirements, for a
representative set of users throughout all the Value Chain;

The design of the Preliminary Architecture of the Final System for the provision of the
identified Services;

The design and development of the Service Prototype Demonstrator built around a set of
functionalities representative of the identified Services;

The identification of operative and economic aspects for the service provision set-up.
The project results were obtained by the execution of trials using a base station and a rover station,
where the rover station was used in 2 situations and the base station was active during both
situations.
The base station purpose was to receive data from EGNOS space segment during all Site Survey
Transfer time of Rover Station. The collected data did represent a base line for post-evaluate the
different cases in which the rover station was during the transfer in urban environment.
The rover station purpose was to “surf” around the city in selected zones and routes of interest
collecting all need data for post data processing. These data were afflicted by all disturb components
of first and second order:

Urban canyon effects;

Foliage coverage;

Multipath

Electro Magnetic Interferences (tram, electric backbones,…)
Main conclusions:
The main conclusions extracted from the analysis of the results of the trial campaigns were:

For each raw location point generated by the professional receiver there was a sigma 5
protection level value associated with it. Sigma is a measure of the level of confidence; 5 is
the associated integrity level, which equates to 99.999% confidence. The receiver derived
these integrity measurements with the aid of EGNOS data, delivered via geo-stationary.

The collected data has demonstrated, in some cases, that the integrity of GPS + EGNOS is too
low to allow it to be used on its own to determine a vehicle’s route. The protection levels for
sigma 5 integrity are too large to be useful in map-matching especially in urban environment
in which the 2 tests have associated only 44 and 12% of the positions to an horizontal
protection level < 25m, respectively.

It is expected that the introduction of Galileo constellation will significantly increase satellite
visibility, improving navigation accuracy by increasing the number of satellites directly visible
from the on-board unit.

The interoperability of GPS and Galileo will permit the visibility of 2 GNSS constellations,
against the current one, having a concrete way of reducing the positioning unavailability in
case of urban canyon and difficult environments.
As a final review, VeRT showed that current GNSS systems are not accurate enough in urban
environments, but the introduction of Galileo is expected to significantly change this scenario,
increasing availability and reduce urban canyon effects.
4.1.2.5. CURACAO
CURACAO (Co-ordination of Urban RoAd-user ChArging Organisational issues) is a new EC funded
project which aims to coordinate research and monitor the results of the implementation of road user
charging as a demand management tool in urban areas. CURACAO is a research and best practice
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
36 of 151
monitoring and coordination action. CURACAO target audiences range from cities where pricing
schemes are already in place to those engaged in a fact finding exercise.
The CURACAO project builds on the work of CUPID, PRoGRESS and EUROPRICE, in the field of urban
road pricing. The consortium comprises a wide range of key partners from those projects along with
the Co-ordinator of IMPRINT-EUROPE and the successor project. The project ensures continuity from
FP5 projects, but also brings in new partners with new ideas to widen the geographic and intellectual
scope of the initiative. The overall objective of the project is:

Coordinate research and monitor the results of the implementation of road user charging as a
demand management tool in urban areas.
The strategic objectives of this project are as follows:

To co-ordinate the synthesis, appraisal, and reporting of research activities, case studies and
other initiatives in the field of urban road user charging.

To compare and contrast different approaches to urban road user charging such as tolling,
distance-based pricing and charges for infrastructure and parking.

To facilitate the exchange of information, raise awareness and disseminate and promote
research results and best practice at a European, national, regional and local level.

To maintain the sound knowledge base, established by the CUPID, PRoGRESS and EUROPRICE
projects to support decision-making and integration of research results into policies.

To ensure that the work undertaken to achieve these objectives is responsive to the needs of
potential end-users, notably city decision-makers.
Main conclusions:
Initiatives such as CURACAO are very important because they help disseminate work already done in
other projects, and help turning results into applicable policies.
Such work potentially avoids duplication of work and helps in the comparison of different approaches
to the same problem.
4.1.2.6. CESARE
CESARE (Common Electronic Fee Collection System for an ASECAP Road Tolling European Service) is a
project set up by ASECAP with the intention of specifying, designing, developing, promoting and
implementing a common interoperable Electronic Fee Collection System (EFC) on European toll roads.
The objective is allowing European users to travel through the overall network and pay for tolls with a
unique technical and contractual means, obtained by signing a contract with one of the possible
providers, under an agreement signed by toll road operators referred to as Memorandum of
Understanding.
Users will have a unique interface to the service, referred to as payment mean issuer, providing a
contractual and a technical instrument (the on-board terminal) to access the service.
The user shall be able to use such instrument throughout the network, receiving then a periodical
statement of the transits performed and an invoice from the same issuer, which will charge him on
behalf of all operators.
Electronic fee collection interoperability is characterised by the following three aspects:

Technical interoperability, intended as a standardisation of the technical characteristics of both
the roadside and the on-board equipment;

Operational interoperability, intended as the standardisation of all procedures involved by the
toll payment through an electronic means, from the distribution to the use of the on-board
terminal, from the charging of the user to the crediting of transport service operators;

Contractual interoperability, intended as the establishment of a contractual instrument binding
signatory parties to provide a service to users along a standardised behaviour.
The overall project can be considered as constituted by 4 different phases:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:

D2.1
15/09/2009
2.0
37 of 151
Phase I: Service definition, technical and operational interoperability
Phase II: Contractual interoperability and feasibility validation
Phase III: Tenders and system implementation
Phase IV: Service roll-out
Phase I closed by the end of 1999 with the result of achieving the basic definition of the technical and
of the operational interoperability.
Phase II started in the year 2001 and ended in February 2002. This second phase touched the
different interoperability levels (technical, procedural and contractual) and provided a whole
framework for interoperability of the EFC systems based on DSRC (Dedicated Short-Range
Communications). The main achievements of Phase II are the following:



Provision of a Memorandum of Understanding (MoU) that defines the behaviour to be
respected by all actors involved;
Definition of an EFC transaction model and the technical specifications for the equipment
needed to perform it;
Investigation of the compatibility between the ASECAP designs and the requirements of nonASECAP countries interested in EFC.
CESARE Phase III started in April 2005 and was successfully completed in September 2006.
CESARE III’s main objective was to study the modifications made to the contractual and organisational
set of documents drawn up in phase II. This needed to take into account the new actors, which for the
first time included countries which have confirmed their participation in a national road toll system,
road toll in urban areas and the EFC European directive.
The project was made up of 7 Work Packages, 5 of which being of technical nature and the remaining
2 being dissemination and project management.
The total budget of the CESARE project amounted to 1,4 M€ and is co-financed by the European
Commission/DG TREN.
A new CESARE model has been introduced and 4 roles to be performed in the European Electronic Toll
Service (EETS) have been identified and put in 4 groups as shown in the figure below:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
38 of 151
Figure 4-8 – CESARE EETS model
Taking into account the newly defined model, the project has then given a new, more detailed
description of its relevant Service Components:
Figure 4-9 – Roles and service components
Main conclusions:
CESARE III proved that the interoperability objectives can become a reality in Europe, if a genuine
and substantial co-operation between the public and the private sector is insured.
Member States who have not yet implemented an EETS, based on the approach set out by CESARE
III, are advised to establish a national implementation plan facilitating the transition of the EETS
obligations, while respecting the open-market requirements of the treaty.
The European Commission, the European Parliament and the EU Member States are invited to
cooperate with the road charging industry and to establish an interoperable EETS, functioning in a
coordinated way at the European level, while allowing Member States to fasten the pace of their
national implementation plans for EETS.
The current project, CESARE IV, is working on defining the contractual relationships between the EETS
entities, in particular between toll chargers and EETS Providers.
4.1.2.7. RCI
The EC co-funded the Road Charging Interoperability (RCI) project to demonstrate and validate how
RCI interoperable prototypes seamlessly, and without user intervention, adapt functional behaviour
when crossing the border according to the rules that apply for the German, Swiss, French, Spanish,
Italian and Austrian tolling schemes. This contracted RCI mission was to be based on specifications
that would be provided by the EC-coordinated expert groups (EFC) and the European Committee for
Standardisation (CEN).
Although the EFC and CEN have delivered a specification for a number of important elements of
EETS, there had not been a clear definition or architecture for the EETS and several of
specifications needed were still missing. RCI therefore defined itself a high-level architecture
interoperability that is based upon work by the CEN and ISO standardization committees and
ASECAP tolling operators’ and Member States’ Stockholm Group role model (CESARE III).
the
the
for
the
The RCI architecture, presented to the EC in February 2007, represented the first European technical
reference for DSRC- and GNSS-enabled road charging solutions that is accepted by the principal
stakeholders (suppliers, toll operators and toll service providers). Through demonstration, validation,
consultation and awareness-increasing workshops, RCI contributed to the further work on the EETS
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
39 of 151
specification, and to the standardisation work within CEN TC 278, to help avoid future deployment of
road charging systems that will delay or block the introduction of interoperability.
The RCI architecture defines what technical interfaces must be implemented in interoperable road
charging solutions to support the exchange of information between the different actors. It will be
these interfaces through which one actor will receive or send information, will monitor or even enforce
another actor.
It will be these interfaces that are crucial for the implementation of the procedural and contractual
agreements made between the actors to ensure interoperability, with the objective being to establish
and keep common trust in the system and operation thereof.
Critical for the contribution that RCI could make to advancing interoperability of road charging
services in Europe, was how as technical reference it was in support of the procedural and contractual
framework that European stakeholders, more specifically the Member States and operators, were
defining in the context of the EETS. RCI documents define the technical interfaces and specifications
that at a very minimum are required for establishing:
• Support for the EETS organisational and contractual model (CESARE III)
• Appropriate market conditions (economies of scale, innovation, competition)
• Trust between Toll Chargers (Member States) and EETS Providers.
Main conclusions:
The RCI project demonstrated that operational interoperability of road charging services in Europe can
be realized on the basis of clear agreements between the different stakeholders. This includes the role
model defining ‘who is responsible for what and what are the contractual relations’, and the technical
architecture defining ‘how and what information is being exchanged’. These two models should go
hand-in-hand and RCI so far is the only technical reference that has the support of 26 leading privatesector stakeholders with proven validity and the RCI architecture proved a suitable basis for this,
showing:
• Support for the EETS (CESARE) role and contractual model
• Basis for required conditions for competitive mass market
• Enabling the establishment of trust between Toll Chargers (Member States) and EETS Providers.
With respect to the first bullet the following results were achieved:
• The RCI prototypes demonstrated functional operation and interoperability of different prototypes in
six existing toll schemes.
• In France, RCI demonstrated that for DSRC-based road charging, a technical implementation of
interoperable road charging can be used up to the procedural and contractual level.
• Validation results showing that processes can be technically implemented on RCI architecture and
consistent with roles and responsibilities as defined by Member States and operators in CESARE.
With respect to the second bullet the following results have been achieved:
• Stimulating innovation and cost reductions: Both ‘thin’ and ‘intelligent’ solutions are being explicitly
supported (Front-End concept) allowing European industry to invest in cost-effective optimised
implementations without further constraints.
• Open, stable and competitive market: Proven starting point for CEN278 WG1 standardization of
stable and pan-European open specifications, creating conditions for a competitive Europe.
• Catalyst for new business: The RCI architecture provides a sound basis for development into a
support framework for Value Added Services, and also provides expertise on how this model could be
built into ongoing Member State procurement programs.
• Economies of scale: Industry can bring to market systems that work with today’s tolling systems,
but which, with the RCI Toll Context Data and architecture definitions, are capable of supporting
future systems as well.
With respect to point 3, the following results were achieved:
• Trust can only be achieved if the Toll Charger can verify the appropriate operation of the EETS as
provided and operated by the EETS Provider and if the EETS Provider can rely on the appropriate
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
40 of 151
infrastructure as operated by a Toll Charger (or Member State). The RCI architecture includes one
clear interface allowing the Toll Charger to perform compliance monitoring.
• Trust also requires that the Toll Charger can have confidence that the correct charge data with
sufficient performance is generated and provided to him.
This requires service monitoring and certification, for which RCI results provide:
• Clear indications and recommendations in a Special Interest Group’s report on Service Certification
and the Type Approval deliverables.
• A clear service interface between the EETS Provider and the Toll Charger in support for this service
monitoring process.
On the basis of the RCI conclusions and lessons learned, the following recommendations were made:
• Continue and finalise the standardisation of the interfaces (CEN) and the work on the contractual
aspects (CESARE IV).
• Define the technical EETS architecture and the interfaces, which are necessary for interoperability as
elements in the EETS definition.
• The responsibility of the EETS Provider for the EETS Front-End including the OBE must be stated
very clearly in the EETS architecture.
• Initialise/coordinate activity envisaging the tools needed for performance monitoring that can help
establishing trust, beyond CE marking.
• Prepare for the EETS (industrial development, pilots, improvements).
• Work with all stakeholders on a clear European roadmap of how progress will be made in the three
years after the decision is finalised. This roadmap should clearly state how the private sector can take
its responsibility in the context of Member State action, European coordination and EC involvement.
4.1.2.8. MISTER
The MISTER (Minimum Interoperability Specification for Tolling on European Roads) was an initiative
taken in 2004 by members of the CEN TC278 standardisation group that had developed the draft
GNSS/CN EFC standard ISO 17575.
ISO 17575 was considered as the basis for the implementation of the EETS, as required by the EC
interoperability directive 2004/52/EC which at that time had just been adopted. But ISO 17575 was
restricted to the definition of aspects of the CN communication interface between on-board equipment
in vehicles and central equipment. As ISO 17575 came into force worldwide, there was a need for a
document defining how it would be implemented when implemented in Europe and worldwide.
MISTER was based on the underlying concepts of ISO 17575. It took the content of ISO 17575, listed
those options applicable for the pan-European EFC service and added technical and procedural
requirements for this service which were not covered by ISO 17575.
MISTER included requirements in the following main areas:

Legal, procedural and contractual framework, regulations and recommendations to be
applied;

Technical and functional requirements: and

Operational requirements.
MISTER did not cover detailed requirements for contractual interoperability, which were the subject of
the CESARE projects, which also needed to be covered in order to guarantee complete interoperability.
The MISTER was intended to provide for “one box” per vehicle to be used in different EFC applications.
The need for the MISTER was superseded when the structure of ISO 17575 was revised and the
results of the RCI project and the expert groups became available.
Standards and interoperability in the road sector are progressing in the right way. Even if very
immature in some aspects, it seems that the standardization activity in some of the most relevant
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
41 of 151
road applications has already achieved some results and the MISTER project can be considered as one
of the references on top of which this process is built.
4.1.2.9. U-OBU
The European Commission’s Directorate General for Transport and Energy (DG TREN) awarded a study
contract to a consortium to define and assess the benefits of a Universal On-Board Unit (UOBU)
enabling telematics services in vehicles across Europe. Started in January 2005 the contract concluded
in October 2006.
The project was conducted in three consecutive stages, each culminating in a high-level document
that cast the findings in a European policy context. These high-level deliverables were underpinned by
more detailed technical documentation that cover the specification, implementation and business case
for the UOBU. The hierarchy of the deliverables was deliberately aimed at appealing to a wide range of
stakeholders from policy makers, safety bodies and government bodies to motor manufacturers,
system suppliers and road operators.
Stage 1, the user needs and systems requirements, implementation scenarios and business case
considerations resulted in deliverable D1, the Requirements Discussion document.
A well-attended stakeholder workshop was held in Brussels and the User Requirements Document
(URD) was issued in July 2005. One of the fundamental findings of the URD was the context diagram
that defined the boundary of the UOBU and with which other systems the UOBU were to interact.
A document was produced on Implementation Scenarios, setting out the possibilities for implementing
the UOBU on various vehicular platforms. The Preliminary Business Case was delivered in September
2005. Stage 2 dealt with system design and technologies, while Stage 3 addressed the feasibility of
the UOBU in technical detail and concluded with a roadmap and recommendations on how the UOBU
could be introduced on to the European transport systems.
The benefits of a pan-European telematics platform were assessed in relation to its acceptability
across the wide ranges of potential users, service providers, road network operators and automotive
industry.
The following represent the final deliverable documents for the UOBU project:
Stage 1




User Requirements
System Requirements
Safety Analysis
D1 - Requirements Discussion Document
Stage 2





Preliminary Analysis of Costs and Benefits
Architecture Options
Implementation Scenarios
Final Analysis of Costs and Benefits
D2 - Options for EU Discussion
Stage 3
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:

D2.1
15/09/2009
2.0
42 of 151
D3 - Roadmap and Recommendations
Since the delivery of the report at the end of 2006 little progress has been made in the further
development of plans for the UOBU. Instead, the focus within the Commission has been on the
definition of the EETS and on specific applications such as eCall.
Main conclusions:
The U-OBU project has shown that:

It is possible to specify an universal OBU that offers 5 key services: location, time,
identification, communications and electrical power;

It is feasible to create an architecture that facilitates the fitment of a basic unit to vehicles,
combined with a telematics platform that manages applications and their relative priorities;

The UOBU can be realised with current mature technologies.
4.1.2.10. RUC R&D initiatives summary
Many studies have been made to prove that GNSS is a viable solution for road user charging. Although
the technology feasibility was already agreed upon, many r&d is still ongoing to prove the economical
feasibility of GNSS and progress to cover the vulnerabilities and weak points which are still associated
to the use of GNSS for this application..
In the meantime, efforts are also being made to create standards enabling interoperability between
different solutions, and potentially reducing the costs of implementation (for example: car makers to
incorporate standard OBUs into their designs).
4.1.3. STANDARDS AND INTEROPERABILITY INITIATIVES RELEVANT TO GINA
This section discusses the following topics:

Standards relevant to GNSS-based RUC;

The Eurovignette directive; and

The current situation on the interoperability directive 2004/52/EC and the planned European
Electronic Toll Service (EETS).
4.1.3.1. Standards relevant to GNSS-based RUC
Working Group 1 of CEN Technical Committee 278 (paralleled by WG5 of ISO TC204) is responsible for
the development of standards for Electronic Fee Collection.
Several standards are relevant to GNSS-based EFC, the most important of which is the ISO Technical
Specification (TS) 17575. This and the other relevant standards are described below.
A number of EFC standards are currently being developed using a number of project teams (PT) set up
by TC 278 WG1 with funding from the Europe Commission.
The following table gives an overview of the project teams PT20-PT32.
PT
Contract work item title
CEN work item title
(full title preceded by Electronic fee collection)
prCEN ISO/TS 17575 Application interface definition for
autonomous systems
PT 20
Electronic Fee Collection based
on GNSS/CN (17575)
Part 1: Charging
Part 2: Communication and connection to the lower layers
Part 3: Context data
Part 4: Roaming
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
PT
PT 21
Contract work item title
Electronic Fee Collection Conformity evaluation of OBE
and RSE"
CEN work item title
(full title preceded by Electronic fee collection)
prEN 15876 Conformity evaluation of on-board and
roadside equipment to EN 15509
Part 1: Test suite structure and test purposes
Part 2: Abstract test suite
PT 22 (A)
Interoperable Monitoring
Application Profile for
Enforcement using DSRC
PT 22 (B)
Interoperable Application Profile prCEN ISO/TS 13141 Localisation augmentation
(IAP) supporting GNSS/CN OBE- communication
localisation augmentation using
DSRC
PT 23 (A)
Interoperable Monitoring
Application Profile for
Enforcement using DSRC
(Conformance evaluation
standard)
PT 23 (B)
Interoperable Application Profile
(IAP) supporting GNSS/CN OBElocalisation augmentation using
DSRC (Conformance evaluation
std)
D2.1
15/09/2009
2.0
43 of 151
prCEN ISO/TS 12813 Compliance check communication
prCEN ISO/TS 13143-1 Conformity evaluation of on-board
and roadside equipment to CEN ISO / TS 12813
Part 1: Test suite structure and test purposes
Part 2: Abstract test suite
prCEN ISO/TS 13140-1 Conformity evaluation of on-board
and roadside equipment to “LAC”
Part 1: Test suite structure and test purposes
Part 2: Abstract test suite
PT 24
Information flows between
Operators of Electronic Fee
Collection (EFC) Systems
prEN ISO 12855 Information exchange between service
provision and toll charging
PT 25
Requirements for a universal
Pre-Payment System for EFC
prTR xxxxx Requirements for pre-payment systems
PT 26
Personalisation of first mount
OBU
prTR xxxxx Personalisation and mounting of first mount
OBE
PT 27
Urban Road Using Charging
requirements
prTR xxxxx Urban requirements for DSRC
second call
(PT 28)
Conformance evaluation of OBE
and CE for EFC based on
GNSS/CN - Parts 1 and 2
NWI proposal(s) and ToR are currently being prepared
second call
(PT30)
Interoperable Application Profile
(IAP) for GNSS/CN based EFC
systems
ditto
second call
(PT 31)
Value Added Services based on
GNSS/CN compatible EFC OBE
ditto
PT 32
Coordination
Coordination of PTs 20 to 31
Table 4-5 – Overview of the project teams PT20-PT32
4.1.3.1.1. ISO TS 17575
This Technical Specification is the Application Interface Definition for EFC systems using GNSS and
cellular network communication. It has been developed over a number years and can be traced back
originally to the recognition for its need following the first GNSS-based trials on the A555 in Germany
in 1994/5. A complete version was produced in 2003 but there were many technical comments and
the whole standard has now been split into four parts and is designed to support interoperable EFC
globally but especially in the context of the European Electronic Toll Service (EETS).
The technical architecture supported by TS 17575 is illustrated in Figure 4-10 – and is independent of
any particular practical implementation. It reflects the fact that some processing functionalities can
either be allocated on the OBE or on an associated off-board component (referred to as a Proxy). An
example of processing functionality that can be implemented either on- or off-board is map-matching,
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
44 of 151
where the vehicle’s location in terms of measured coordinates from GNSS are associated to
geographic objects on a map that either resides on- or off-board. Also tariffication (i.e. charge
calculation) can be done with OBE tariff tables and processing, or with an off-board component.
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Back End
Front End
Road Usage Data
Context Data
Figure 4-10 – Assumed technical architecture and interfaces
The combined functionality of OBE and Proxy is referred to as Front End. A Front End implementation
where processing is predominately on the OBE-side is known as a smart client (or intelligent client, fat
client or thick client) or edge-heavy. A Front End where processing is mostly done off-board is denoted
as thin-client or edge-light architecture. Many implementations between the “thin” and “thick”
extremes are possible, as depicted by the gradual transition in the wedges in Figure 4-10 –. Both
extremes of architectural choices have their merits and are one means where manufacturers compete
with individual allocations of functionality between on-board and central resources.
Especially for thin client OBE manufacturers may devise a wide variety of optimisations of the transfer
of localisation data between OBE and off board components, where proprietary algorithms are used for
data reduction and data compression. Standardisation of this transfer is neither fully possible nor
beneficial.
In order to abstract from and become independent of these architectural implementation choices, the
primary scope of TS 17575 is the data exchange between Front End and Back End, see the
corresponding dotted line in Figure 4-10 –. For every toll regime, the Back End will send context data,
i.e. a description of the toll regime in terms of charged objects, charging rules and if required the tariff
scheme to the Front End, and will receive usage data from the Front End.
It has to be noted that also the distribution of tasks and responsibilities between Service Provider and
Toll Charger will vary individually. Depending on local legal situation, Toll Chargers will require
“thinner” or “thicker” data, and may or may not leave certain data processing tasks to Service
Providers. Hence, the data definitions in TS 17575 may be useful on several interfaces.
TS 17575 also provides for basic media-independent communication services that may be used for
communication between Front End and Back End, which might be line-based or an air-link, and can
also be used for the air-link between OBE and central communication server.
TS 17575 is a suite of four specifications, as follows:
17575-1 – Charging: this defines the attributes for the transfer of usage data from the Front End to
the Back End, and ultimately to the individual Toll Charger. The required attributes will differ from
one Toll Charger to another, hence, attributes for all requirements are offered, ranging from attributes
for raw localisation data, for map-matched geographic objects and for completely priced toll
transactions.
17575-2 – Communication and connection to lower layers: this part defines basic communication
services for data transfer over the OBE air-link or between Front End and Back End.
17575-3 - Context Data: this defines the data to be used for a description of individual charging
systems in terms of charged geographical objects and charging and reporting rules. For every Toll
Charger’s system, attributes as defined in part 3 are used to transfer data to the Front End in order to
instruct it which data to collect and report.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
45 of 151
17575- 4- Roaming: this part defines the functional details and data elements required to operate
more than one EFC regime in parallel. The domains of these EFC regimes may or may not overlap.
The charge rules of different overlapping EFC regimes may be linked, i.e. they may include rules that
an area pricing scheme shall not be charged if an overlapping toll road is used and already paid for.
The four parts of TS 17575 are being finalised by Project Team 20 (PT20); Parts 1 and 2 are currently
(April 2009) being submitted for formal voting, with a view to their adoption by the end of 2009; Parts
3 and 4 will be submitted for formal technical commenting in May 2009 and are expected to be
adopted by mid-2010.
Formal work items for four two-part standards for the conformance evaluation of each of the four
parts of TS 17575 are currently (i.e. April 2009) being defined, with a view to appointing a new
project team (PT28) and for preparation of the 8 conformance evaluation standards for adoption
before the end of 2010.
4.1.3.1.2. TS 17573
This Technical Specification (currently a pre-standard, prEN) deals with system architecture for
vehicle-related tolling. It encompasses architecture for both DSRC- and GNSS-based tolling and
provides a framework which is consistent with the work of a number of projects, in particular RCI and
the CESARE projects, as well as the standards developed or being developed within TC 278 WG1.
Figure 4-11 – shows the basic roles and responsibilities which are assumed in the 17575 architecture.
The two-way arrows between roles are meant to indicate collections of interactions. Interactions to
and from the management role are management information flows, while interactions between the
three other roles are operational information flows of the Toll Charging environment, i.e., information
flows that are present during daily operation.
Figure 4-11 – Roles in the Toll Charging environment
4.1.3.1.3. TS 12855
This standard identifies and specifies the interactions between two classes of roles defined in prEN ISO
17573, which are the roles related to the Provision of Toll service (‘Service Provider’) and the roles
related to Charging of the Toll (‘Toll Charger’). To do this, this standard uses the Enterprise
description of the Toll environment, and the interactions defined between the named classes of roles,
as defined in prEN ISO 17573. This allows for a complete specification of the data that is transferred
between those identified entities. In addition to that, a number of computational interfaces are
identified, where interactions in terms of sequences of messages are defined.
The key data for defining toll contexts (toll context data) and for providing charge data form a major
part of the 12855 definitions. They are taken directly from 17575 parts 3 and 1 respectively.
4.1.3.1.4. TS 12813 and TS 13143
Technical Specification 12813 defines requirements for DSRC communication between an OBE and an
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
46 of 151
interrogator for the purpose of checking compliance of the road use with the local toll regime. The
specification assumes an EFC services architecture according to prEN ISO 17573, see Figure 4-12 –
Interoperability
Management
Service
Provision
Toll
Charging
Service
Usage
Compliance Check
Communication
Figure 4-12 – Compliance Check Communication in the EFC architecture of prEN ISO 17573
Toll Chargers have the need to check whether the road is used in compliance with the rules in the
local toll regime. One way of checking compliance is to observe a passing vehicle and to interrogate
the OBE. This interrogation happens under control of an entity responsible for Toll Charging, see
Figure 4-12 –.
The interrogation is accomplished via short range communication between an interrogator at road-side
(or in another vehicle) and the OBE. In an interoperable environment it is essential that this
interrogation communication is standardised such that every operator of compliance checking
equipment can check all passing OBE. For this purpose this Technical Specification defines attributes
that shall be available on all OBE for reading by an interrogator.
The two-part standard TS 13143 provides for conformity evaluation of on-board and roadside
equipment to TS 12813.
4.1.3.1.5. TS 13141 and TS 13140
Technical Specification 13141, Localisation Augmentation Communication (LAC) for autonomous
systems, defines requirements for short range communication for the purpose of augmenting the
localisation in autonomous (i.e. GNSS-based) electronic fee collection systems. Localisation
augmentation serves to inform OBE about current geographical location and about the identification of
a charge object. This specification covers provision of location and heading information and security
means to protect manipulating the OBE with fake RSE.
The localisation augmentation communication takes place between an OBE in a vehicle and fixed roadside equipment. The specification applies to OBE in an autonomous mode of operations.
The Specification defines attributes and functions for the purpose of localisation augmentation by
making use of the DSRC Communication Services provided by DSRC Layer 7, and makes these LAC
attributes and functions available to the LAC applications at the RSE and the OBE.
The two-part standard TS 13140 provides for conformity evaluation of on-board and roadside
equipment to TS 13141.
4.1.3.2. The Eurovignette Directive [RD.15]
The ‘Eurovignette Directive’ 2006/38/EC, adopted in May 2006, amends the previous Directive
1999/62/EC covering the application of taxes, tolls and user charges for heavy vehicles. The new
directive extended the scope to vehicles over 3.5 tonnes. It allows EU Member States to charge for
the use both of the trans-European road network and of other roads where necessary, e.g. for tackling
congestion. The Directive does not require Member States to levy tolls and charges for lorries, but
where they choose to do this they must respect the rules in the Directive. The Directive is intended to
address distortions of competition between transport undertakings in the Member States, by at least
partial harmonisation of the way that infrastructure costs are charged to hauliers.
The key provisions of the Directive are that:

GINA
Tolls and user charges should be transparent and non-discriminatory;
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:



D2.1
15/09/2009
2.0
47 of 151
Tolls for existing tolling schemes must be related to infrastructure costs and for new tolling
schemes tolls must be calculated in accordance with some more detailed rules;
Frequent user discounts must be limited to 13%; and
Variation of charges (eg. by time of day or environmental class of vehicle) must be within
specified bounds.
The Commission has proposed that so-called external costs of noise, air pollution and congestion in
road freight transport would be charged for via supplements in HGV tolls. However, essential
elements of the proposal, in particular charging for congestion costs, have caused heated discussions.
On 11th March 2009, the European Parliament came out broadly in favour of the Commission’s
proposal following a controversial debate on more than 500 amendment proposals in the first reading.
Nevertheless, charging for congestion costs is the subject of much disagreement within the European
Parliament.
EU Transport Ministers failed to reach agreement on a revision of the Eurovignette Directive at their
spring meeting in March 2009. There was no majority in favour of a compromise proposal from the
Czech Presidency. As a result, discussions on the revision of the directive will continue on the basis of
the political statements by Transport Ministers.
4.1.3.3. The interoperability directive and the EETS
The ‘Interoperability Directive’ 2004/52/EC provides rules for the implementation and operation of
Electronic Toll Collection (ETC) in Europe. It provides for the establishment of the “European
Electronic Toll Service” (EETS).
All new ETC systems in Europe are required to adhere to European standards, and are encouraged to
be based on Global Navigation Satellite Systems (GNSS). However, established microwave ‘tag and
beacon’ technology at 5.8 GHz is acceptable.
When it was adopted in April 2004, the Directive envisaged that by 1 st July 2006 there would be
agreement reached on the definition of the EETS, and then required Member States to offer EETS
services with three years for heavy vehicles and within five years for all vehicles.
The Commission established a number of research and development projects and ‘expert groups’
intended to help with the definition of the EETS. However, in practice it was difficult to reach
agreement, and the deadline for agreement was postponed initially for a year and then indefinitely. In
March 2009 Member States voted to accept a draft Commission Decision which lays out the high level
definition of the EETS. The Commission expects the Decision formally to be adopted by July 2009;
this will start the periods for required implementation, meaning that Member States will have to
ensure EETS availability for heavy vehicles by mid-2012 and for all vehicles by mid-2014.
The EETS decision is based on the expectation that interoperable EETS units will be offered by a
number of ‘EETS Providers’; these will be private sector organisations established in different
European countries, and they will be expected to offer a certified service acceptable to charging
authorities (‘Toll Chargers’) throughout Europe. EETS Providers will sign agreements with every Toll
Charger offering an ETC service, and will collect toll and other charges due from their customers and
transfer the fees due to the Toll Chargers. EETS Providers may well offer a range of additional
services, or Value Added Services, in addition to the EETS.
It is not expected that every Toll Charger will be an EETS Provider, nor that each Member State will
need to have its own EETS Provider.
The implications for an ETC operator wishing to adhere to the requirements of the Directive are that
he makes an agreement with each certified EETS Provider in order to be able to accept users with onboard equipment provided by the Provider.
The organisational architecture proposed for the EETS follows the recommendations produced by the
CESARE projects (see 4.1.2.6), and is illustrated in the CESARE EETS model, reproduced in Figure
4-13.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
48 of 151
Figure 4-13 – CESARE EETS model
The technical architecture for the EETS is based on that developed in the RCI project (see 4.1.2.7)
and illustrated in Figure 4-14. This illustrates the concept that a service provider may choose whether
his OBE uses a ‘thin’ or ‘thick’ client architecture: as long as the interface between toll chargers and
EETS service providers is standardised, and the EETS Service fulfils certain minimum requirements
and performance levels (which have yet to be fully defined), then the service provider does not need
to use a standardised interface to communicate between his own back office and the OBE for which he
is responsible.
Toll Charger
ETC system
Driver
Vehicle
EETS service user role
1
2
Service point
Toll charger role
3
4
OBE
5
EETS proxy
EETS Front-End
EETS Back-End
EETS provider role
Figure 4-14 – CESARE EETS model
The current draft of the formal EETS decision introduces the concept of a national conciliation body,
which each Member State would be required to establish, whose function would be to resolve disputes
between toll charges and EETS Providers.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
49 of 151
The draft Decision also proposes the appointment of notified bodies which would be responsible for
certification of EETS services.
4.1.3.4. Standards and Interoperability Summary
There are a number of European (CEN) standards which are relevant for Electronic Toll Collection,
referred to in the standards as Electronic Fee Collection (EFC). The following standards either have
already been adopted or are expected to be adopted within the next two years.
Reference
Description
ENV ISO 14904
Interface specification for clearing between operators (adopted
2002,revision of ENV ISO 14904:1997)
EN ISO 14906
EFC application interface definition for DSRC (adopted 2004-03, revision of
ENV ISO 14906:1998)
CEN ISO/TS 14907-1
EFC Test procedures user and fixed equipment - Part 1: Description of test
procedures (published 2005-03-16, approved by CEN 2004-03 and by ISO
2004-09, revision of ENV ISO 14907-1:1999)
CEN ISO/TS 14907-2
EFC Test Procedures user and fixed equipment - Part 2: Conformance test
specification for onboard units (approved 2005-01)
EN 15509
Interoperable application Profile for DSRC (adopted 2007-02)
CEN ISO/TS 17573
EFC System architecture for vehicle related transport services (adopted
2002-10)
CEN ISO/TS 17574
EFC security services framework – guidelines for EFC security protection
profiles (adopted 2003-09. Proof-read for publication 2004-07)
CEN ISO/TS 25110
Electronic Fee Collection - Interface definition for on-board account using
ICC; expected adoption 2009
CEN ISO 17573
EFC System architecture: expected adoption 2009-07
CEN 12855
Information Exchange between Service Providers and Toll Chargers:
expected adoption 2010-01
ISO TS 17575
Application Interface Definition for EFC systems using GNSS and cellular
network communication; suite of 4 parts. Parts 1 and 2 expected to be
adopted 2009-10, parts 3 and 4 expected to be adopted 2010-07
The ‘Eurovignette Directive’ 2006/38/EC, adopted in May 2006, amends the previous Directive
1999/62/EC covering the application of taxes, tolls and user charges for heavy vehicles. The new
directive extends the scope to vehicles over 3.5 tonnes. It allows EU Member States to charge for the
use both of the trans-European road network and of other roads where necessary, e.g. for tackling
congestion. The Directive does not require Member States to levy tolls and charges for lorries, but
where they choose to do this they must respect the rules in the Directive. The Directive is intended to
address distortions of competition between transport undertakings in the Member States, by at least
partial harmonisation of the way that infrastructure costs are charged to hauliers
The key provisions of the Directive are that:




Tolls and user charges should be transparent and non-discriminatory;
Tolls for existing tolling schemes must be related to infrastructure costs and for new tolling
schemes tolls must be calculated in accordance with some more detailed rules;
Frequent user discounts must be limited to 13%; and
Variation of charges (eg. by time of day or environmental class of vehicle) must be within
specified bounds.
The ‘Interoperability Directive’ 2004/52/EC provides rules for the implementation and operation of
Electronic Toll Collection (ETC) in Europe. It provides for the establishment of the “European
Electronic Toll Service” (EETS).
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
50 of 151
All new ETC systems in Europe are required to adhere to European standards, and are encouraged to
be based on Global Navigation Satellite Systems (GNSS), although established microwave ‘tag and
beacon’ technology at 5.8 GHz is acceptable.
Despite delays there has been considerable progress made in the definition of the EETS; interoperable
EETS units will be offered by a number of ‘EETS Providers’; these will be private sector organisations
established in different European countries, and they will be expected to offer a certified service
acceptable to charging authorities (‘Toll Chargers’) throughout Europe. EETS Providers will sign
agreements with every Toll Charger offering an ETC service, and will collect toll and other charges due
from their customers and transfer the fees due to the Toll Chargers.
It is not expected that every Toll Charger will be an EETS Provider, nor that each Member State will
need to have its own EETS Provider.
The implications for an ETC operator wishing to adhere to the requirements of the Directive are that
he makes an agreement with each certified EETS Provider in order to be able to accept users with onboard equipment provided by the Provider.
4.2. VALUE ADDED SERVICES
In order to have an Innovative Road Application we need to have an On Board Unit (OBU) which has
the capacity to collect the location and velocity of a vehicle for each time stamp together with a
bidirectional communication system. Combining the collected values and the communication capability
and with other elements we have what we call Value Added Services. These services give to the user
(vehicle user, road operator or authorities) extra information beyond the simple localization of the
vehicle.
There are several kinds of Value added services. Some examples are: Traffic information systems, Pay
As You Drive, Fleet Management, Freight and Transport Management and Navigation services.
All of them are possible to implement with the actual GPS, nevertheless the GPS is not considered Safety and Liability
critical. Those factors are important, especially to the Traffic Information Systems and the Pay As You Drive services.
With the introduction on the EGNOS / Galileo with better measurement accuracy and availability, these services can
be deployed as trusted services to the end user. This document will focus mainly on these two kinds of services.
On the Traffic information systems the position and timing information is used to send and receive
traffic information. The following types of services can identified:

Authorities traffic management

Road statistics

Reception of traffic information by zones

Report traffic information to other user (vehicle users and road operator)

Security and Assistance service like vehicle localization in case of emergencies or vehicle
stolen
On the Pay As You Drive services the position and timing information is used to calculate vehicle
usage fees. Two major services can be identified on this category:
Insurance companies use the localization and timing to evaluate driver characteristics and charge
insurance based on that. Several driver characteristics can be identified namely the type of roads
used, the velocity, the distance, how much time and when is the vehicle used.
Car leasing and Car renting companies use the system to track the car localization and usage like
distance measurement. Extra charge can be applied for unexpected behaviours. Car telemetric can
also be used for example to track fuel spent.
Other services like Fleet, Freight and Transport Management use the localization information to track car and/or
goods. A special case is the dangerous goods transportation routing, monitoring and enforcement.
All these Value Added services must be standardized in the future. There is also a sub-chapter
regarding the current standardization activities.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
51 of 151
4.2.1. OVERVIEW OF PAYD AND OTHER VAS SOLUTIONS RELEVANT TO GINA
4.2.1.1. Pay As You Drive (PAYD)
Pay As You Drive has many applications in the real world, but the most common are insurance
companies and car-leasing companies.
Let’s say that 2 individuals make insurances for their vehicles in the same insurance company. Neither
of them had any accident registered, they are about the same age and they drive the same type of
vehicle. In summary, they are quite similar to the insurance company and will pay the same amount.
But one thing that can’t be measured by a conventional insurance is the driver behaviour. The
kilometres travelled, the areas driven, the speed limit compliance, etc.
By applying a PAYD insurance scheme, the insurance company is promoting a safer driving behaviour
because, the more one drives, the more one pays. Also, the way one drives is extremely important
and will be taken into account when billing the customer.
This way, a more cautious driver, respectful of the law, that eventually drives less kilometres than
others, will significantly pay less for his insurance.
The following sections give an overview of some PAYD systems examples:

PWYD (Portugal)

Proyecto Generación Y (Y-CAR) (Spain)

Maaf (France)

Norwich Union (United Kingdom)

Hollard (South Africa)

MyRate - Progressive (USA)
Besides this described PAYD solutions, there are also some other functioning systems across Europe,
such as in Italy through Octotelematics and in France through Amaguiz.
In technical terms all presented systems are very similar. They all use the same technology, GNSS, as
the basis for their products. In all cases, vehicles use an OBU to calculate insurance values with
proper communication to a central system for processing and billing.
4.2.1.1.1. PWYD (Portugal)
PWYD stands for “Pay What You Drive” and regards a developed system that focus on vehicle
insurance policies, calculating the adequate value of the insurance focusing the vehicle usage. The
vehicle usage is estimated through the analysis of several indicators, such as the traveled distance,
the usage time and average speeds.
The global architecture of the system is very similar to other developed intelligent road traffic
systems, and consists in an onboard unit (OBU) installed in every vehicle and a central back office
facility that collects and processes all the information.
The OBU used in the system is composed by:

GPS localization module

GPRS mobile communications

Serial port and Bluetooth connection
The main factors identified by Via Directa Seguros company to contribute to the proper estimation of
the insurance value were:


GINA
Amount of travelled distance
o
Travelled distance by zone (rural zone, urban zone, dense urban zone)
o
Travelled distance by type of road (highway, main road, secondary road)
o
Travelled distance by specific road (streets with special conditions)
o
Travelled distance in zones with higher risk of accident
Average speed by type of road
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:

Speed alarms

Usage times

o
Usage during rush hour
o
Usage during week days
o
Usage during weekend
D2.1
15/09/2009
2.0
52 of 151
Position alarm in case of accident
This system is currently being prepared to be commercialized.
4.2.1.1.2. Proyecto Generación Y (Y-CAR) (Spain)
The Proyecto Generación Y was a project developed by the Mapfre insurance company currently
commercialised under the name Y-CAR. In this project, the company has proposed to gather 10000
clients with ages between 18 and 27 years old available to install in their vehicles equipment that
allows GPS positioning. The main purposed is to perform a study regarding the common driving
characteristics of this particular sample of population that allow achieving several conclusions
concerning the main causes of the incidents. The installation costs of the required equipment are fully
supported by the insurance company.
In the study are analyzed the following driving characteristics:

Travelled distance

Percentage of the used type of roads

Average time performed

Most frequently driving hours

Driving zones

Percentage of night driving

Average speeds
4.2.1.1.3. Maaf (France)
Maaf PAYD product is open to the insured or prospective insured whatever their age and their vehicle.
Specifically, 3,000 vehicles - the Maaf has 3.5 million members - were equipped with a GPS and GSM
case, gathering information such as driving time, hours (including driving at night and weekends) or
type of routes. Installation costs (between 50 and 100 euros) were supported by Maaf and its partner
Steria.
At the outset, the Association offers premium reductions to those who try the experiment: 8% for
those who claim to make less than 12,000 km in the year and 12% less than 8000 km. For the
moment, especially Maaf seeks to establish the system of feedback.
Only after the data is fully collected and analysed (in an anonymous and aggregated way), the PAYD
mechanism will be fully implemented, supporting more clients.
4.2.1.1.4. Norwich Union (United Kingdom)
Norwich Union, a United Kingdom insurance company, recruited 5,000 customers to participate in a
pilot program which began in late 2003 to test the benefits and demand for PAYD insurance and
associated services. The service commercialisation was in late 2006.
The company collected data using a “black box” installed in participant vehicles, a technology
developed by IBM. Using technology similar to that used for mobile phones, the “black boxes”
provided to Norwich Union, information about how often, when, and where a vehicle is driven. Monthly
insurance payments can be calculated from that data. Policy holders may pay a monthly premium to
cover the basics like fire and theft protection, and then may pay itemized add-on charges reflecting
vehicle usage.
Norwich Union believes this method of calculation ultimately results in fairer premiums and provide
the customer greater control, flexibility, and choice. Response to the online registration for the pilot
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
53 of 151
has been overwhelming and the company expects to receive more than the required number of
volunteers.
By mid 2008, this service was paused and taken out of the market due to a lack of customer adoption
and high operational costs. The main costs came from the need of installing the OBUs on every
insured vehicle. Norwich Union expected motor manufacturers to install telematics devices in the
vehicles at the point of manufacturing, but that did not come to be.
Ultimately, when economical factors are more favourable, Norwich Union considers a possibility to
bring the service back to the market once again.
4.2.1.1.5. Hollard (South Africa)
The PAYD solution provided by Hollard Insurance, uses a GPS tracking device to calculate factors to
tax in the insurance premium.
Hollard PAYD solution has no age restriction for its clients and the insurance premium is calculated on
a monthly basis, based on the number of kilometres driven taking into account.
The monthly fee and the price per kilometre are variable and calculated based on the risk category of
the vehicle driver.
The only restriction imposed by the insurance company is the vehicle class, not being possible to
ensure:

Taxis;

Rebuilt and/or modified vehicles - limited cover;

Vehicle modified for commercial purposes - Emergency, Towing, Armed Reaction vehicles;

Vehicles used by or for courier services;

Vehicles used to carry trade goods for business purposes.
4.2.1.1.6. MyRate - Progressive (USA)
Progressive Insurance has begun offering PAYD insurance in six American states under the name of
MyRate.
Drivers who sign up for MyRate will install a small wireless device in their cars that transmits to
Progressive not just how many miles they drive but also when those miles are driven and, to some
extent, how they are driven: the device measures the car’s speed every second, from which
Progressive can derive acceleration and braking behaviour. Which means that Progressive will not only
be able to charge drivers for the actual miles they consume but will also better assess the true risk of
each driver.
This plan could, of course, simply result in less revenue for Progressive, since low-mileage drivers will
pay less for their insurance. If Progressive raises rates on high-mileage drivers to compensate, there's
nothing to stop them from switching to other insurance companies. However, if Progressive’s PAYD
insurance can induce some of its high-mileage customers to drive less and especially to drive more
safely, resulting in smaller claims payouts for Progressive and fewer negative externalities for
everyone, then it could truly be a win-win-win situation.
4.2.1.2. Traffic Management and Information
Traffic information and provision is a key element to highway controllers, concessionaires and urban
traffic managers. Without it, it is impossible to know the traffic situation in the areas being controlled.
Information gathered and stored over time is essential for management decisions and planning of road
infrastructure improvements.
The more granular this information, the closer to reality the data also is. This way, the more
information a system provides, the better.
The use of GNSS to monitor traffic can improve the current situation by providing real time vehicle
positioning, not only on measurement locations, (like in traditional solutions where vehicle counting
and monitoring is made in fixed locations (by using DSRC or Vehicle classifiers using loop detectors)
but everywhere on the monitored road.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
54 of 151
The next sections give an overview of some traffic information examples systems:

RITA

ADvantis (GSA)

MORYNE
4.2.1.2.1. RITA (Portugal)
RITA stands for Road Intelligent Traffic Application and it is a product oriented to road traffic
management and road safety improvement. The RITA Product was implemented in a modular
approach, allowing easy adaptations to any road topology and road equipments. This product is,
nowadays, installed in several highway concessions in Portugal, being operated by AENOR.
The RITA is a road traffic management application that has the following objectives:

Provide traffic management capabilities, allowing an easy, dynamic and safe highway
management;

Perform counting and classification of vehicles in order to perform shadow tolling;

Provide direct monitoring and control of the road equipments installed in the highway;

Provide fault management, by handling the different faults of the various controlled
equipments. It also has the capability to manage fault information provided by the operators;

Provide road alarms management that includes real-time warnings and ability to respond
adequately;
Being traffic management the main focus of RITA, the main traffic management functionalities present
are:

Management of highway situations – RITA allows the complete management of road
situations, from its occurrence to its closure. When the highway operator detects (either
alerted by the system or by self detection) any of these types of situations, it is possible to
include specific data related with the situations in hand that is helpful to classify and manage
it. In all types of situations it is also possible to provide automatic information to the drivers
using the variable message signs installed on the highway. The situations that can be handled
by RITA are:
o
Incidents – related to situations in the road that can become hazardous to the drivers.
It includes accidents, vehicles stopped on the highway, animals on highway and
several others.
o
Road works – indicates the location of road works.
o
Weather Information – indicates weather conditions that can be hazardous to the
drivers.
o
Equipment Faults – indicates the failure or malfunctioning of the equipments installed
in the highway.
o
Traffic Information – provide ad-hoc information to the drivers.

Road Alarm Management - This functionality is characterized by the dynamically definition of
action plans in order to provide a respond to road alarms in real-time. The main focus of this
is to implement automatic responses and suggest groups of actions to be performed, by the
operator, when a road alarm is detected.

Geo-referenced map of the highway – This is the main operation interface of RITA. This map
allows the operator to verify in real-time the status of the entire highway, to directly control
the road equipments, and to verify specific data from the road equipments (status, medium
velocity and road volume, messages present in the panels, etc.).
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
55 of 151
Figure 4-15 – RITA Map Interface
Main conclusions:
The RITA modular architecture and integrated functionalities are an example of how several VAS can
be operated by the same central system. Currently only conventional traffic management technologies
are used by RITA, such as automated traffic counters or CCTV. Evolution to new technologies such as
GNSS, DSRC or ANPR are feasible for RITA and will allow it to support new and improved
functionalities, alongside the current ones.
4.2.1.2.2. ADvantis (GSA)
The main ADvantis project objective was to define a system and business model that could provide
position, velocity and time with integrity (PVT-I) under a Service Level Agreement (SLA) using EGNOS
and Galileo. This project was developed under the Galileo Joint Undertaking 1st call for projects.
The key issues addressed by ADvantis were distributed by technical, legal, risk and business areas.
The technical issues considered were:

ADvantis Integrity concept;

Integrity in non-controlled environments;

Alternative means for GEO broadcast (SISNet).
The legal issues considered were:

Legal and regulatory framework applicable;

Data Privacy / Confidentiality.
The risk issues considered were:

GINA
Insurance and risk management.
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
56 of 151
The business issues considered were:

Application type approval;

User equipment certification;

Standardization;

Interoperability.
The ADvantis architecture is based on a centralized system shown in the figure below.
Figure 4-16 – ADvantis architecture
The clients are companies and organizations like insurance companies, highway operators or
governments who in turn use the data collected by the Central Unit to provide their services to the
end users, such as individuals using a personal digital assistant or vehicles equipped with an OBU.
The central unit uses GPRS technology to collect positioning information (PVT-I) from the OBUs and
PDAs.
One of the main goals of this architecture is to provide liability-critical position information.
The development of the project was divided into 3 main phases:

Phase 1: Concept development and system definition;

Phase 2: Prototype downscaling and trials definition;

Phase 3: Trials execution, analysis and results dissemination.
In phase 3 there were 2 trials pre-selected: Integrated Urban Traffic Management and Legal Zone
Restriction for Individuals. Both are very different in nature which demonstrates the flexibility of the
ADvantis architecture.
Main conclusions:
For the conclusions, ADvantis demonstrated that Integrity is central for liability critical applications.
Its service flexibility was achieved with the “single OBU/Multiple applications” approach, proving that it
works.
Traffic Management based on GNSS information can be viewed as a liability-critical application since
errors in the management process can lead to the opposite of the desired effect, like the increase of
congestion problems and ultimately the cause for accidents.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
57 of 151
Data privacy and security were also achieved, proving that the concept is reliable in terms of user
privacy.
4.2.1.2.3. MORYNE [RD.12]
Project MORYNE (EnhanceMent of public transpORt efficiencY trough the use of mobile seNsor
nEtworks) was a particular case of Local Road Traffic Management System (LRTM), developed under
the European Comission FP6, focusing:

MORYNE focused on traffic in urban and sub-urban areas.

MORYNE addressed the issues of Public Traffic Management and City Traffic Management.

MORYNE considered using Public Transport vehicles (buses, tramways) as elements of a
network of mobile sensors.
Figure 4-17 – MORYNE architecture
With the combined Public traffic management and City traffic management scenario, project MORYNE
was focused on:

The development of an approach for new safety and efficiency-oriented transport management
and traffic management.

The development and validation of technologies for appropriate sensing, information
processing, communication, interfaces.

The development of an in-laboratory demonstrator.

The validation of the proposed concepts through field testing.

The analysis of potential impacts (social, economic, environmental) and the definition of
further steps.
Main conclusions:
The main vision of MORYNE was the creation of a unified traffic management system distributed
through local traffic management systems that can interoperate.
The main conclusions of MORYNE are distributed in 4 aspects:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
58 of 151

Economic – partnerships with neighbouring public agencies and the private sector can facilitate
data sharing and help defray the initial and recurring costs of field sensors, communications
infrastructure, central hardware, and processing software;

Industrial – the usage of environmental sensor stations, mobile sensing devices and remote
sensing systems allow for road and city traffic operators to become more aware of the current
traffic situation and to take actions on a more informed base and more rapidly;

Environmental – By proper traffic management measurements the environmental damages
can be reduced and the social impacts of the transports will be improved. The mobile sensor
usage can support this activity and the sustainable development of transports. It provides
awareness of meteorological and actual traffic situation by acquiring real-time data.

Social – The application of environment evaluating methods, investments cost-benefit
analyses, estimation of the changes occurred on the environment quality and in he value of
natural resources induces social benefits for the society. The reduction of external costs,
appropriate pricing, elaboration of rules for the environmental protection and preparing the
necessary investments can be accomplished with a well functioning traffic management
system.
4.2.1.3. Other VAS
The following sections address systems and R&D projects aimed at other value added services than
PAYD or Traffic Information.
4.2.1.3.1. COOPERS
COOPERS stands for CO-OPerative SystEms for Intelligent Road Safety and is an European research
and development (R&D) and innovation activity within the Call 4 (Co-operative Systems and in vehicle
integrated safety systems) of the 6th Framework Programme by the European Commission.
COOPERS provides vehicles and drivers with real time local situation based, safety related status and
infrastructure status information distributed via dedicated Infrastructure to Vehicle Communication
link (I2V).
This approach extends the concepts of in-vehicle autonomous systems and vehicle to vehicle
communication (V2V) with tactical and strategic traffic information which can only be provided by the
infrastructure operator in real time. I2V in this respect will significantly improve traffic control and
safety via effective and reliable transmission of data fully adapted to the local situation of the vehicle
(ensemble of vehicles). I2V will extend massively the responsibility and liability of the infrastructure
operator compared with today in terms of reliability and accuracy of information to advice
drivers/vehicles. The highest effect of I2V communications will be achieved in areas of dense traffic
also known as areas where risk of accidents and traffic jams is extremely high.
The real time communication link between infrastructure and vehicle can also be used vice versa for
V2I communication utilising vehicles as floating sensors to verify infrastructure sensor data as primary
source for traffic control measures.
Benefits provided to road users:

traffic jam warning and guidance

in-car display and alert of area-specific speed limits

lane specific, selective ban of lorries

estimated time of arrival, based on current traffic situation on the network

car breakdown/emergency services
And for network operators:

enhanced traffic management based on floating car data

safety related information for drivers, speed and distance proposal

data exchange between operators for international seamless service handover

monitoring of transport flows and information exchange for changing demands of transport
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
59 of 151
Figure 4-18 – COOPERS architecture
Main conclusions:
COOPERS present a series of benefits for both drivers and operators. It has demonstrated that EGNOS
can be used in conjunction with other vehicle components (odometer, integration with other vehicle
sensors from the CAN-Bus) to create a robust positioning unit that can be used in conjunction with
traffic control centers to create cooperative systems that can create awareness of real-time traffic
conditions and safety conditions.
4.2.1.3.2. GST
GST (Global System for Telematics) was an EU-funded Integrated Project that was creating an open
and standardized end-to-end architecture for automotive telematics services.
The purpose of GST was to create an environment in which innovative telematics services can be
developed and delivered cost-effectively, and hence to increase the range of economic telematics
services available to manufacturers and consumers.
GST’s vision was to create an open environment in which innovative telematics services can be
developed and delivered cost-effectively. Thereby, the range of services that will become available to
manufacturers and consumers will increase.
Drivers and occupants will be able to rely on their on-board integrated telematics system to access a
dynamic offer of on-line safety, efficiency and comfort-enhancing services wherever they drive in
Europe.
They will be able to access their portfolio of services throughout Europe using the same vehicle
terminal.
Main conclusions:
GST results made it possible for service providers, control centre providers and manufacturers of client
systems to develop, provide and manage services in service centres, control centres and on-client
systems in as interoperable way.
The project showcased vehicle-to-vehicle communication, emergency call, service deployment, remote
service management, safety channel messages, remote payment capability, service certification and
many other aspects related to automotive telematics.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
60 of 151
4.2.1.3.3. COM2REACT
The COM2REACT (Cooperative communication system to realize enhanced safety and efficiency in
European road transport) project proposes to enhance traffic safety and efficiency by using, between
in-car systems and regional control centres, a local control layer. This intermediate level is called
Virtual Sub Centre (VSC). The VSC layer ensures (using V2V communication) an efficient diffusion of
relevant information in the VSC vehicles cluster and the safety/efficiency applications are built using
this information. The COM2REACT system also includes information sharing with the regional control
centre (RCC) when relevant.
The COM2REACT project aims at proving the VSC concept, its usefulness and its market potential. The
Virtual Sub-Centre (VSC) is the guideline concept of COM2REACT. A VSC manages a moving group of
vehicles in close proximity. VSC is a middle control level aiming at enhancing the reactivity of the
systems by faster communication and information processing.
The VSC can be regarded as a group of vehicles with a common knowledge base. Through the
immediate and continuous exchange of information every vehicle can benefit from this improved
information in its individual decision. As a result, the behaviour of the entire group can be better
adjusted to the dynamically changing traffic situations.
The added value of the VSC concept can be briefly described as follows:

Local communication is much faster than remote communication and can therefore enable an
immediate reaction to sudden events.

Distribution of information by the VSC can be better directed to the relevant vehicles and,
subsequently, avoid information overload.

The VSC together with the RCC constitutes a hierarchical traffic information and
communication structure, where vehicles on the local level are mainly self-organized but then
additionally controlled by the traffic management system on the regional level.
Summarising
The developed safety applications were able to detect selected hazards. These hazards are congestion
back-ends, broken down vehicles, vehicles involved in accidents and slowly moving vehicles on
motorways. Inattentive drivers due to fatigue or consumption of alcohol are also COM2REACT hazards.
The developed algorithms were based both on available CAN-Bus data and on special sensor data. The
C2R vehicles are equipped with cameras, a laser telemeter and a DAISY sensor.
Algorithms for traffic state recognition, lane assessment and obstacle detection were developed and
available to the safety applications.
4.2.1.3.4. GOODROUTE
Several thousands of trucks carrying dangerous goods circulate within European roads on daily basis.
They utilize urban roads, rural roads, highways, tunnels and long bridges and in some case they are
not allowed in some of them. But the actual accident risk and impact when using secondary roads or
other alternative ways is not calculated. In addition, when due to unforeseen events (traffic jams,
accidents, etc.) they need to change route, they do not have any particular guidance on the safest
alternative nor are consequences of road choice to the business chain and societal risk calculated.
GOOD ROUTE aimed to develop a cooperative system for dangerous goods vehicles routing,
monitoring, re-routing (in case of need), enforcement and driver support, based upon dynamic, real
time data, in order to minimise the Societal Risks related to their movements, whereas still generating
the most cost efficient solution for all actors involved in their logistic chain. This project was developed
under the European Comission FP6.
Summarising
For this scope, a new classification scheme of the dangerous goods with infrastructure based safety
measures, context of transportation (i.e. level of loading) and vehicle characteristic were performed,
dynamic data collection and fusion were realised from Infrastructure to Vehicle (I2V)/ Vehicle to
Vehicle (V2V) sources and a series of on-board sensors, risk calculation algorithms were realised,
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
61 of 151
leading to a new route guidance function, the "minimum risk route guidance". The system was
integrated with an automatic, local node based, enforcement functionality and tested in 3 Pilots
throughout Europe (in Finland, Switzerland and Italy), with emphasis in densely populated areas,
tunnels and bridges. In addition, rerouting info and estimated delays were communicated to the
vehicles logistic chain, thus optimally combining safety with transportation efficiency enhancement.
4.2.1.4. VAS Solutions Summary
The initiatives presented in the previous sections show that the most common VAS application of
GNSS is in PAYD solutions, with different levels of success.
In addition to the current market orientation, the current research trend is to explore the usage of
GNSS in road safety, therefore several projects (COOPERS, COM2REACT, GOODROUTE) address this
issue.
Traffic management has also been addressed, and currently implemented solutions are very limited,
when compared with the possibilities brought forward by GNSS.
4.2.2. STANDARDS AND INTEROPERABILITY INITIATIVES RELEVANT TO GINA
Within the standardisation committee TC 278, Working Group 1 (EFC) is currently preparing a new
work item to investigate the requirements for standards to support value added services (VAS) in
conjunction with GNSS-based EFC systems. It is planned to prepare formal Technical Report which will
provide advice on how to continue with the expected feasibility of reusing GNSS-based EFC OBE for
VAS.
Currently the boundary between services based on EFC OBE without any additional equipment and
comfort service platforms is not clearly visible. Therefore the scope of this formal work item will
include investigation of whether or not the expectations for VAS mentioned in the interoperability
directive are feasible. And if yes, are the available sensor information, data elements, communication
media and HMI features suitable supporting the envisaged mass services like fleet management,
hazardous goods/ life stock management as well as e-call. The second question is how they can be
implemented without jeopardising the security requirements of the Service provider responsible for
the OBE and with that the charging process. The possibilities and constraints, including privacy
requirements as defined in 95/46/EC and as discussed in art. 29 group on privacy, to integrate
OBU/OBE within a wider open platform approach to deliver other public or private added value
services, the required standards and anticipated road map form part of the investigation.
4.3. LESSONS LEARNED, POTENTIAL RISKS AND MITIGATION
STRATEGIES
4.3.1. RELEVANT ISSUES ENCOUNTERED IN OTHER PROJECTS
A complete survey of all the lessons learned in the above projects is outside the scope of this report.
This section has the objective of listing a number of issues that were encountered in the initiatives
mentioned above, that are also believed to be relevant to GINA.
There are 2 main types of issues encountered: General issues regarding both RUC and VAS and
specific RUC issues. The next sections distinguish general issues from specific issues.
4.3.1.1. General Issues Encountered
This section describes the main general issues encountered. These issues may be distributed into
economical, technical, interoperability, regulatory and legal aspects.
Road side infrastructure costs
Installation and maintenance of road site equipments can become very costly. Gantries supporting
variable message signs, radars or DSRC receptors, PTZ cameras, ANPR cameras or toll booths are
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
62 of 151
examples of common road side equipment necessary for the correct operation of current road tolling,
traffic management and traffic information gathering.
When one moves from low complexity highway networks to urban roads network, soon realizes that it
is not feasible to install this kind of infrastructure inside an urban environment.
Possible solution/mitigation:
GNSS solutions do not have this problem since they rely on minimal road side infrastructure, thus
presenting a less costly implementation and a higher flexibility when the need comes to adapt to new
tolling policies.
Cost effectiveness
Compared to traditional road side infrastructure, GNSS can be a more cost-effective solution,
depending on the size and complexity of the road network – urban, highway or a mix of both. The
larger the dimension of the system to implement, the more cost-effective a solution based on GNSS
can be.
However, GNSS is still not oriented for small scale solutions, for example, tolling on highways,
because of the costs associated with the installation of OBUs and the operational costs of the system.
Examples are the Austrian HGV tolling system which is a DSRC-based solution for heavy vehicles
tolling, and the London congestion charging technology trials that demonstrated that GPS accuracy is
not enough to implement congestion charging (or RUC for urban traffic) without the help of virtual
gantries.
[RD.10] reinforces this idea by considering DSRC the best option for a motorway tolling solution for
the Netherlands, and GNSS as the best solution for more complex road networks due to its high
flexibility, allowing charging every road, from dirt road to highway.
Furthermore, [RD.10] compares several technologies, such as DSRC, GNSS, Tachographs, ANPR and
cell phone technology, and makes investment and exploitation estimates for the situation in 2005 and
the predicted situation for 2020 in the Netherlands highway network and national vehicle fleet.
The following table presents a summary of the results presented on [RD.10]. Cell phone technology
cost was assumed to be similar to GNSS.
For the calculations it was assumed a vehicle fleet of 9000000 vehicles in 2005 and an estimate of
13500000 in 2020. It was also assumed that 7836 roadside equipment sites were necessary in 2005,
from which 1567 were to have enforcement capabilities, while in 2020 there would be 15672
locations, from which 3134 were also enforcement sites.
Technology Investment (2005) Investment (2020) Exploitation (2005) Exploitation (2020)
DSRC
4163378
8000506
91092
182184
ANPR
11597280
23194560
5210940
10421880
Tachograph
13363164
20527578
27932
55864
8795664
13676328
27932
55864
GNSS
Table 4-6: Cost comparison estimate for Kilometre-charging systems (M€)
From 2005 to 2020, the number of vehicles and highway network is expected to grow, and this is
what justifies the cost increases. Another result taken that is not explicit on this table was that
roadside equipment costs have a very high importance in DSRC systems, around 90%, while the
roadside equipment necessary for a GNSS solution is basically used for enforcement and represents
around 40% of the total costs. This allows us to conclude that by increasing the road network
complexity, and implicitly increasing the number of roadside equipment necessary makes DSRC
significantly more expensive, while with the progress of technology OBUs can become significantly less
expensive, making GNSS even more attractive.
The following table gives us a more detailed comparison of the costs associated with each technology
when the road network complexity increases. This was done by multiplying the assumed complexity
for the Netherlands highways in 2005, found on [RD.10]. It must be kept in mind that the complexity
associated with a nationwide road network is much higher than the one presented in the table.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
63 of 151
Network Complexity
Low (Highway)
Double
Triple
9000000
9000000
9000000
9000000
Roadside
7836
15672
23508
31344
Enforcement
1567
3134
4702
6269
7263972
9685296
11597280 23194560 34791840
46389120
Vehicles
Quadruple
Road Network costs (M€)
DSRC
ANPR
2421324
4842648
Tachograph
666060
1332120
1998180
2664240
GNSS
666060
1332120
1998180
2664240
OBU Costs (M€)
DSRC
450000
450000
450000
450000
ANPR
0
0
0
0
Tachograph
8550000
8550000
8550000
8550000
GNSS
5400000
5400000
5400000
5400000
Back office + Indirect Costs (M€)
DSRC
1292096
2381692
3471287
4560883
ANPR
5218776 10437552 15656328
20875104
Tachograph
4147227
4446954
4746681
5046408
GNSS
2729727
3029454
3329181
3628908
7674340 11185259
14696179
ANPR
16816056 33632112 50448168
67264224
Tachograph
13363287 14329074 15294861
16260648
Total Costs (M€)
DSRC
GNSS
4163420
8795787
9761574 10727361
11693148
Table 4-7: Road Network complexity – cost relation (M€)
The following figure summarizes the total costs progression according to the road network complexity.
The conclusions taken from this figure are that the cost progression of DSRC clearly surpasses GNSS
when we triple the road complexity, showing that GNSS becomes more attractive for more complex
networks. The Tachograph also becomes more attractive than DSRC for complex systems, but doesn’t
have the value added that GNSS presents and its OBU is also more expensive.
ANPR is clearly inadequate for complex networks.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
64 of 151
Figure 4-19 – Road Network complexity – cost relation (M€)
On top of this, DSRC and ANPR-based systems have other limitations that GNSS overcomes with its
high flexibility allowing to easily expand/update the road network and change the tolling scheme
without significant costs. Also, a thick OBU could support several services at once, creating new
market opportunities and therefore, more revenues.
Possible solution/mitigation:
The bottom line is that GNSS cost effectiveness is higher as the road network complexity.
Implementation of GNSS on low complexity networks depends mainly of the OBU price reduction.
On Board Unit (OBU)
The OBU is a key element for most systems, being more or less complex according to the solution
they are designed for. This complexity may influence the cost of installation. For example, a typical
DSRC system (Via Verde, Via-T) usually mandates the installation of a simple OBU, normally placed on
the vehicle’s front window. On the other hand, GNSS based systems, which in turn offer more and
better value added services; need a more complex OBU that usually connects to other vehicle systems
through the CAN network to access components like the odometer.
It is easily understood that the simpler the OBU is, the less money, time and expertise is necessary to
install it.
Another important factor regarding the OBU and the services it provides to the driver is the map it
may contain to support its services. Although a map update may be a simple task, the usage it
requires from the communications network (GSM, GPRS, UMTS) may be too expensive, both in
economic matters for the entity running the system, but also for the network load when considering
every vehicle circulating on every road in a country.
Possible solution/mitigation:
OBU costs may be reduced by standardizing the OBU (see U-OBU for a viable example) and
convincing car makers to integrate them in their vehicles on manufacturing.
One way to avoid communication costs is to create offline update alternatives, such as map updates
through an USB device. The user could download the updates from a personal computer through a
broadband connection, with almost no cost implication, and upload it to the OBU through an USB
device.
Communication
Two problems arise in this subject. Both were mentioned earlier when addressing the OBU:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:

Telecommunication costs;

Firmware updates (map updates, services interface updates, OBU BIOS updates).
D2.1
15/09/2009
2.0
65 of 151
When considering the communications needed to operate a GNSS based system one must take into
account that every vehicle might be updating its position regularly (depending on the adopted solution
and the road tolling requirements) and transmitting it back to the central back office for services
management and toll charging. Considering even a small amount of data transmitted in every update,
globally there will be a significant amount of data loading the network that will be billed to the system
provider.
Possible solution/mitigation:
See On Board Unit (OBU) solutions.
Back-office
GNSS based systems must naturally have more complex systems for tolling support, for traffic
information and provision support, and for other potential value added services. Assumptions about its
capabilities may still play a role in other design decisions. It is important to make these assumptions
explicit, and analyze them properly.
Most of the value added services provided to drivers may be supported by the back office making it an
even more complex system.
In a commercial point of view, there must be a clear advantage in terms of costs, and that includes
back office operation costs, compared to the ones we have nowadays. Even with the increment of
complexity, the costs associated to it must not rise too much.
Possible solution/mitigation:
The back-office extra operational and implementational costs could be negated by creating extra
revenues from the value added services that GNSS enables for operators. In fact, these revenues may
as well surpass the extra costs and become a positive factor for the adoption of GNSS.
Integrity, reliability and credibility of the system
In order for authorities to be able to charge the road’s usage, it is necessary to previously
demonstrate the integrity and reliability of the charging system to the end users, demonstrating to the
users that all provided measurements have a certain level of confidence proper for charging.
An integrity-critical application can be sub-classified as:

Safety-critical (or safety-of-life): if an un-warned error of the positioning system can result in
death or physical injuries to human beings.

Liability-critical: if an un-warned error of the positioning system can result in undesired
economic or legal consequences, such us damage of goods, loss of money, illicit charges of
fees or taxes, etc.
Another important factor is also the reliability of the system, where it shall be guaranteed the proper
operation of the system for a determined period of time.
The system’s credibility is also a key factor to accomplish an appropriate charging system. This
feature is achieved by a system that properly proves its integrity and reliability, and can be enforced
by crossing information from several sources, such as GNSS systems, odometers and other road side
equipment (ANPR, DSRC, Wi-Fi).
Possible solution/mitigation:
New GNSS solutions may take advantage of EGNOS integrity services and in the future of Galileo
signal authentication for improved reliability and credibility of the system.
Standardization
A factor complicating the adoption of GNSS based technology for tolling is the near absence of
standards and their difficult adoption. Standards are required to create an open and competitive
market, and to ensure that European drivers do not end up with a different ICS for each regional or
national road-pricing scheme.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
66 of 151
Possible solution/mitigation:
EC should regulate on the adoption of standards by the Member States.
Regulation and legal framework
In very broad terms, there are three main groups of legal issues raised by the functions provided by
the GINA project, and are related with:

Restrictions to personal freedom;

Privacy;

Safety (equipment, information provided) and related liability aspects.
These matters have different levels of legal protection, (e.g. Constitutional, European Union legislative
protection, or internal laws and/or regulations) and, depending on the relevant “Service Functionality”,
there might be different levels of assessment related with its potential unconformity or incompliance.
Possible solution/mitigation:
All Member States should be encouraged to adopt similar regulations and internal laws for the road
sector. These regulations should be broad enough not to become unconstitutional in any state.
Use of satellite navigation in general for heavy goods vehicles
Route planning for HGVs is more complicated than for passenger vehicles, because of the additional
constraints that HGVs have for road usage. These constraints concern width restrictions, weight limit,
access restrictions, severe gradients, risk of grounding and roads not allowed for dangerous
transports. Taking all these factors into account on the implementation of a satellite navigation system
will make it much more complex than a regular navigation system commonly found in any electronics
shop.
In particular, the navigation map must contain more information, making it more complex and its
updates larger.
Possible solution/mitigation:
By having different authorities providing information and contributions for different layers of
information on such a map, the work of creating it could be minimized, requiring only one coordinator
institution that would provide to the general public final releases and updates of maps built on
information from different authorities/institutions.
Certification
Equipments used for charging purposes need to be certified, just like traditional vehicle counting
devices. In the case of value added services, for most of them this is not the case, i.e. a personal
navigational device does not need to be certified, but a PAYD system needs to be.
Possible solution/mitigation:
To ease certification efforts, EC should regulate on the certification requirements for GNSS-based
equipments, making them uniform through all Member States. By doing so, a device already certified
by a Member State could be used in other Member States without the need for re-certification.
4.3.1.2. Specific RUC Issues Encountered
This section describes the road user charging specific issues. These issues are mainly related to
technical aspects.
Limitations of current systems
Current systems related to road tolling are either limited to the roads they cover or the type of
vehicles they support.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
67 of 151
Those systems that toll heavy goods vehicles only on highways create a new problem which is the
reroute of trucks to urban and suburban roads in an attempt to cut toll costs. This issue brings traffic
problems to areas where they didn’t exist before, like excess noise and environment pollution or traffic
congestion.
Possible solution/mitigation:
By adopting GNSS for HGV tolling, countries like Slovenia, Sweden and Slovakia are already
addressing this issue. Using GNSS enables them to toll HGV on virtually every road, and this way
negating the advantages of HGV rerouting.
Enforcement and the potential complexity of an enforcement system
In order to implement an adequate charging system, it is important to consider the usage of several
technologies that might be translated in a better overall performance of the system. This enforcement
is expected to bring better results, but also to introduce a higher complexity to the system, which is
typically encountered in the integration of the several technologies and the crossing of the information
collected.
The enforcement of a GNSS system can be achieved using several technologies, such as odometers,
ANPR and DSRC.
Possible solution/mitigation:
Since most countries already have operational tolling systems, these can be minimized and become
enforcement systems for future GNSS solutions.
Mobile ANPR is also a viable option for enforcement since they can be installed in police patrol
vehicles, turning them into mobile enforcement stations, capable of detecting infractions in real-time.
Security and privacy aspects
A key factor to guarantee the adoption of GNSS in the road sector is the privacy of the data collected
from every OBU. Legal problems may arise in the case of security breaches which might lead to
privacy violation. With this in mind, all data must be encrypted using the latest in cryptographic
technology.
Possible solution/mitigation:
Implemented systems must be tested for security flaws and should use state-of-the-art security
technology.
Precision and accuracy
Several issues arise when addressing precision and accuracy, since these are very important subjects
to the adoption of GNSS.

Detect position on parallel nearby roads, with different tolling schemes. This may lead to a wrong
calculation of the toll to pay. To minimize this problem in case it occurs, whenever in doubt, the
system must always opt for the less expensive toll for the driver;

Reducing the time to get a first lock on the satellites after start of the vehicle from a position
where no satellite signals can be received. If a vehicle runs several kilometres without a lock it
can’t be taxed for those kilometres. This problem becomes more serious depending on the
visibility of an area;

Interaction between the design of the charging scheme, and the capabilities of the technology,
helping governments design a scheme that works for GNSS technology;

Placement of virtual gantries, and the need for them. This is a relevant issue since gantries do not
cover an entire segment or zone like other geo-objects. They simply detect the passing of
vehicles, making their positioning hard to determine. It is arguable if virtual gantries should even
be used instead of other geo-objects.
Possible solution/mitigation:
With the introduction of the Galileo constellation and the EGNOS augmentation features, most of the
problems described can be mitigated.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
68 of 151
Billing
User expectations about billing are of extreme importance. For example, 10 times exactly the same
trip from Bremen to Hamburg must result in 10 times the exact same cost, and that the trip costs
exactly the same in both directions.
Possible solution/mitigation:
The concept of a ‘trip’, how it appears on a bill, what defines the start and what defines the end are
issues to be taken into account when designing a system.
4.3.2. POTENTIAL RISKS AND MITIGATION STRATEGIES
Below we list some risks in abstract terms that have been encountered in other tolling projects, and
that may well be encountered in GINA.
Identified Risks
Possible Mitigation Strategies
Implicit technology assumptions  Being careful about making all technology assumptions
wrong assumptions about current or explicit,
identify
technological
developments
and
future
developments

wrong expectations about future developments
engineering decisions (Toll-collect)
Technology driven  not sufficient Careful analysis of market requirements and other
attention to the non-technological requirements relevant to standardization, regulation, policy,
obstacles for market acceptance
interoperability etc., and of the requirements of all parties
that need to agree to adopt the technology.
Implicit cost model assumptions 
engineering
decision
based
on
erroneous assumptions of costs  nonoptimal product for the future market
place
Make cost assumptions explicit, and try to make realistic
assessments of the way in which costs will change in the
next five years (e.g. mobile data telecommunication costs).
KMP studies are good source for realistic cost assumptions.
Duplication of work done elsewhere in Continuous and close monitoring of parallel projects that are
parallel
project
(e.g.
GIROADS, currently being carried out in the field of satellite based
ARMAS)  unnecessary costs and traffic services.
possibly irrelevance of work done in
GINA
Table 4-8 – Identified risks and mitigation strategies
4.3.3. LESSONS LEARNED SUMMARY
The following table summarizes the main issues related to the adoption of GNSS by the road sector.
Title
Road
costs
side
Type
infrastructure General
Description
Current systems depend on costly road side equipment
Cost effectiveness
General
Cost-effectiveness depends on the scale of the solution. The
larger and complex, the more attractive to GNSS
OBU
General
Cost of installation and firmware updates
Communication
General
Telecommunication costs associated with the OBU-Central
System communication can become high, depending on the
adopted RUC scheme and the data transmitted by value added
services built on top of the solution. Real-time position update
is clearly costly, especially when considered a nation-wide
vehicle fleet. Map updates are also an issue if there are VAS
dependant on it.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Title
Type
Back office
D2.1
15/09/2009
2.0
69 of 151
Description
General
The wider the system, the more complex a back office might
be. This will potentially increase it’s operational costs
and General
Integrity is required for safety and liability-critical
applications. GNSS reliability must not be questionable
otherwise the technology will loose credibility and fail to be
adopted
General
Slight progress has been reported in this area, but still there
is a lot to be done to standardize GNSS solutions and promote
interoperability
legal General
There are many privacy concerns about the adoption of GNSS
technology for every-day use of individuals
Use of satellite navigation General
for HGV
HGVs have more restrictions than regular private vehicles.
This potentially means specific OBUs with more complex maps
Certification
General
Solutions need to be certified to be accepted as a charging
tool. There is the need to create one certification authority to
standardize certification requirements. This could enable for
example, that a solution certified in Spain could be implement
in France without the need for re-certification.
Limitations of current
sytems
RUC
There aren’t systems capable of covering an entire array of
possibilites in the road sector. Some are limited to HGV
tolling, others to highway tolling and others to urban tolling.
Integrity,
credibility
reliability
Standardization
Regulation
framework
and
GNSS brings the possibility to create an all-in-one solution.
Enforcement and potential
complexity
RUC
The higher the system complexity, the higher the potential
cost of enforcement. Need to consider the usage of different
technologies that might be translated into a better overall
performance of the system
Security and privacy
RUC
Security and privacy must be always guaranteed. The user
data must never be jeopardized or made public. Also, no
single institution should have access to all the data needed to
associate an OBU or a vehicle to a specific individual.
Precision and accuracy
RUC
To become a viable solution for RUC, any technology must
show high levels of precision and accuracy. If there are too
many errors, the system will loose a large percentage of
charges which in turn corresponds to a loss of revenue.
In the other hand, users must not pay more than the
expected for the road/local they are driving, so in case of
error, the system should never tax them and therefore, loose
even more revenue.
Billing
RUC
User expectations are to be taken into account. For that, any
solution must define very explicitly the concept of a trip, it’s
start and end, and how it appears on a bill
Table 4-9 – Lessons learned summary
The most important issues for the adoption of any technology are its cost-effectiveness compared to
others, its reliability and efficiency (precision and accuracy). For any new technology to be adopted it
must bring new features to the targeted market, even if only economy advantage,
In the case of GNSS for the road sector there is a need to prove its cost effectiveness. Regarding its
technical details, it brings several advantages when compared to other solutions, being one of the
most important, its flexibility, which is able to support several different services at the same time as a
way to capitalize on top if a possible RUC solution.
GINA project aims at proving that this claim is true, by implementing a full featured demonstrator
capable of supporting not only RUC functionalities, but also VAS functionalities at a large scale.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
70 of 151
4.4. OVERVIEW OF OTHER TECHNOLOGIES RELEVANT TO GINA
This chapter presents an overview of relevant technologies to GINA, either because they are
commonly adopted on other current implemented solutions (ANPR, DRSC, GSM), because they may be
used for enforcement (ANPR, DSRC) or because they are communication options to be used during the
implementation phase of the GINA prototype (GSM, UMTS, VANET, CALM).
4.4.1. ANPR
ANPR (Automatic Number Plate Recognition) systems use optical character recognition software to
convert images of vehicle registration numbers into information for real time or retrospective
matching with law enforcement and other databases.
ANPR systems essentially comprise two components:

Data capture

Data exchange and analysis
Data capture involves mechanisms to gain and read an image of a vehicle number plate (registration
plate).
Most jurisdictions require that motor vehicles be identified through an alphanumeric sign at the front
and rear of that vehicle, with the sign generally being of a standard size and a common font.
The identification 'numbers' on that plate are drawn from a register maintained by the particular
jurisdiction. That database typically features information about ownership of the vehicle and may be
tied to a discrete database of registered drivers, i.e. those people with a drivers' license.
In principle, ANPR provides a basis for any scheme that is restricted to or that leverages vehicle
registration information. Applications developed using this technology, have thus included:

Traffic congestion management (differential pricing for use of roads in a precinct)

Traffic speed restrictions

Offender identification (unregistered, uninsured, stolen vehicles, fake number plates)

Criminal intelligence (location of terrorism suspects and 'persons of interest to the police')

Generation of blacklists of vehicles seeking fuel or other products from petrol stations
4.4.2. DSRC
Currently, the existing road tolling systems implemented in Europe are mainly based in the DSRC
(Dedicated Short Range Communication) wireless protocol.
On a toll, the DSRC system is the component that is responsible for controlling the communications
with the vehicles. Basically, a DSRC system can be divided in two main blocks:

The mobile unit, typically placed in the front glass and possesses a unique ID for each highway operator;

The fixed equipment, typically placed at the road side, composed of an antenna that
communicates with the mobile unit, and a controller that converts the signals received by the
antenna and transmits them to the application controlling the lane.
The mobile unit, commonly known as OBU (On Board Unit), is a passive identifier that every time it
enters on the toll area reacts to the signal sent by the antenna and responds with its own ID. Some
OBU allows the antenna to write data on them, which can be used later to calculate the price to pay.
The fixed unit is the component that is responsible for establishing the communication with the OBU,
translating the low levels signals of the air interface into application commands. Basically, the
application commands generated by the fixed unit are of two types: signaling and reporting.
A signaling message is delivered to the application every time a car passes under the antenna and it
was able to read the ID from the tag. If the car passes under the antenna but there was also a
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
71 of 151
malfunction an extra reporting message is generated. These reporting messages can be of various
types like low battery, tag open, etc.
This microwave technology, which is currently used by the majority of European countries employing
road toll systems, is hardly constrained by its lack of interoperability, which difficult the compatibility
between the different national systems.DSRC may be applied to enforcement of a GNSS-based system
by taking advantage of the fact that DSRC systems can be found all over Europe, specially on
highways and bridges. This way, DSRC may be used on specific trials involving highways and/or
bridges, by just comparing GNSS results to local DSRC results whenever possible.
Comparing the usefulness of ANPR with DSRC for enforcement, DSRC is quite limited, since ANPR
systems can be found inside cities, parking lots and even highways and bridges making ANPR more
flexible when considering already installed systems. Also, several ANPR mobile solutions may be found
on the market at relatively low costs if no local ANPR or DSRC system may be used during trials.
On the other hand, using an ANPR solution for enforcement does not require a pre-installation of
additional hardware on the vehicles, while DSRC does.
4.4.3. VEHICLE’S ON-BOARD DIAGNOSTIC SYSTEM
EOBD (European On-Board Diagnosis) is the European standard counterpart for the American OBD-II
standard. Since 2000 all gasoline powered vehicles must have an EOBD system and diesel vehicles
since 2003. A standard connector for accessing the system must be present in the car cockpit.
EOBD standard defines a set of test routines that the car computer must perform over a set of sensors
and/or ECUs connected through a serial link. When an error occurs it is stored for later analysis or a
dashboard light is set depending on error seriousness. The test routines enforce gas emission policies
and monitor critical vehicle systems.
The EOBD system allows also retrieving real-time data from car sensors using the EOBD connector
and a scan device. Useful data includes speed, kms, etc.
The EOBD connector will only allow the monitoring of car ECU parameters and logs, it will not allow for
the change of any ECU data or behaviour.
It’s quite easy to find EOBD scan devices and software in the market. It is also quite simple to
implement an EOBD to RS232 adapter for PC usage or integration with another device with a RS232
port.
4.4.4. CONTROLLER AREA NETWORK BUS (CAN-BUS)
The CAN (Controller Area Network) is an ISO-defined serial communications bus that was originally
developed during the late 1980's for the automotive industry. CAN was first established for automobile
by Bosch GmbH in mid 1986. It was developed based on the request from Mercedes and BMW when
they faced difficulties in connecting or sharing data between ECU (Electronic Control Units). It was
difficult to connect the ECU with conventional UART (Universal Asynchronous Receiver/Transmitter)
since the UART is only suitable for point-to-point transmission, multiple nodes are not allowed in this
communication system. The first CAN chip was available in 1987 by Intel. After that, many companies
adopted the CAN technology to develop higher-level protocols.
Its basic design specification called for a high bit rate, high immunity to electrical interference and an
ability to detect any errors produced. Not surprisingly due to these features the CAN serial
communications bus has become widely used throughout the automotive, manufacturing and
aerospace industries.
The CAN communications protocol describes the method by which information is passed between
devices. It conforms to the Open Systems Interconnection model, which is defined in terms of layers.
Each layer in a device apparently communicates with the same layer in another device. Actual
communication is between adjacent layers in each device and the devices are only connected by the
physical medium via the physical layer of the model. The CAN architecture defines the lowest two
layers of the model: the data link and physical layers. The application levels are linked to the physical
medium by the layers of various emerging protocols, dedicated to particular industry areas plus any
number of propriety schemes defined by individual CAN users.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
72 of 151
Data Layer:
ISO 11898-1 defines the CAN Data Layer protocol which is a message oriented one. Medium access is
trough message priority. A unique message identifier exists for each possible message, this identifier
includes the message priority. Priorities are assigned at design time and cannot be changed
dynamically.
Physical Layers:
A CAN high-speed physical layer is defined by the ISO 11898-2 standard.
The physical medium is a two-wire bus line with common return terminated at both ends by resistors
representing the characteristic impedance of the line. The theoretically maximum bus length is 40 m
at a data rate of 1M bit/s.
At bit rates lower than 1M bit/s the bus length may be lengthened significantly. The maximum bus
length is 1 km allowing a maximum data rate of 50 kbit/s.
CAN fault-tolerant low-speed physical layer:
There are different fault-tolerant physical layers specified for CAN-based networks. The ISO 11519-2
standard will be withdrawn very soon, the ISO TC22 SC3 WG1 standardization group has initiated a
new work item proposal regarding a CAN fault-tolerant physical layer, ISO 11898-3, which will
substitute ISO 11519-2. The new fault-tolerant transceiver specification will specify low-power
consumption and switch-off modes as well as wake-up procedure.
In order to provide a maximum communication speed of 125k bit/s the overall network length should
not exceed 40 m. However it is possible to increase the overall network length by reducing the actual
communication speed.
The most significant feature of all fault-tolerant physical layers is the capability to perform a singlewire transmission in case of short-circuits of one bus-line against ground or battery voltage. Shortcircuits between both bus-lines lead also to a single-wire transmission.
CAN by itself isn’t enough for establishing a production network environment, since it goes no higher
than the OSI Data Layer. A high level protocol (HLP) or a high level stack is needed. A great amount
of work was, and still is, put into the development of HLPs and available options are many:

Keyword Protocol 2000.

CANOpen.

CanKingdom.

OSEK-VDX.

Smart Distributed System (SDS).
4.4.5. MOBILE COMMUNICATION PROTOCOLS
4.4.5.1. GSM/GPRS
The Global System for Mobile (GSM) communications is a digital cellular communications system. It
was developed in order to create a common European mobile telephone standard but it has been
rapidly accepted worldwide. GSM was designed to be compatible with ISDN services.
The GSM family of wireless communications is a living and evolving family that already offers an
expanded and feature-rich 'family 'of voice and data enabling services. The GSM family consists of
General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE) and third
generation GSM services (3GSM).
GSM is a very complex standard. It can be considered as the first serious attempt to fulfil the
requirements for a universal personal communication system. GSM is then used as a basis for the
development of the Universal Mobile Telecommunication System (UMTS).
The GSM technical specifications define the different entities that form the GSM network by defining
their functions and interface requirements.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
73 of 151
GPRS is an add-on to existing GSM networks that brings packet-switched capabilities to the GSM
world. GPRS is an ETSI standard and has been widely deployed over Europe’s and Asia’s GSM
networks.
The main objectives to be reached by implementing GPRS are the following:

Give support for bursty traffic

Use efficiently network and radio resources

Provide flexible services at relatively low costs

Possibility for connectivity to the Internet

Provide fast access time

To have and support flexible co-existence with GSM voice
4.4.5.2. UMTS
3G Systems are intended to provide global mobility with a wide range of services including telephony,
paging, messaging, Internet and broadband data. International Telecommunication Union (ITU)
started the process of defining the standard for third generation systems, referred to as International
Mobile Telecommunications 2000 (IMT-2000). In Europe, European Telecommunications Standards
Institute (ETSI) was responsible of UMTS standardization process.
UMTS offers teleservices (like speech or SMS) and bearer services, which provide the capability for
information transfer between access points. It is possible to negotiate and renegotiate the
characteristics of a bearer service at session or connection establishment and during ongoing session
or connection. Both connections oriented and connectionless services are offered for Point-to-Point
and Point-to-Multipoint communication.
Bearer services have different QoS parameters for maximum transfer delay, delay variation and bit
error rate.
Offered data rate targets are:

144 Kbits/s satellite and rural outdoor;

384 Kbits/s urban outdoor;

2048 Kbits/s indoor and low range outdoor.
UMTS network services have different QoS classes for four types of traffic:

Conversational class (voice, video telephony, video gaming);

Streaming class (multimedia, video on demand, webcast);

Interactive class (web browsing, network gaming, database access);

Background class (email, MMS, downloading).
A UMTS network consist of three interacting domains; Core Network (CN), UMTS Terrestrial Radio
Access Network (UTRAN) and User Equipment (UE). The main function of the core network is to
provide switching, routing and transit for user traffic. CN also contains the databases and network
management functions.
The basic CN architecture for UMTS is based on GSM network with GPRS. All equipment has to be
modified for UMTS operation and services. The UTRAN provides the air interface access method for
User Equipment.
4.4.5.3. VANET
The Vehicular Ad-Hoc Network, or VANET, is a technology that uses moving cars as nodes in a
network to create a mobile network. VANET turns every participating car into a wireless router or
node, allowing cars approximately 100 to 300 meters of each other to connect and, in turn, create a
network with a wide range. As cars fall out of the signal range and drop out of the network, other cars
can join in, connecting vehicles to one another so that a mobile Internet is created. It is estimated
that the first systems that will integrate this technology are police and fire vehicles to communicate
with each other for safety purposes.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
74 of 151
VANET offers countless benefits to organizations of any size. Automobile high speed Internet access
would transform the vehicle’s on-board computer from a nifty gadget to an essential productivity tool,
making virtually any web technology available in the car. While such a network does pose certain
safety concerns (for example, one cannot safely type an email while driving), this does not limit
VANET’s potential as a productivity tool. It allows for “dead time” - time that is being wasted while
waiting for something - to be transformed into “live time” - time that is being used to accomplish
tasks. A commuter can turn a traffic jam into a productive work time by having his email downloaded
and read to him by the on-board computer, or if traffic slows to a halt, read it himself. While waiting in
the car to pick up a friend or relative, one can surf the Internet. Even GPS systems can benefit, as
they can integrate with traffic reports to provide the fastest route to work. Lastly, it would allow for
free, VoIP services between employees, lowering telecommunications costs.
4.4.5.4. CALM
CALM is a standardized draft series of air interface protocols for ITS services and applications, under
the acronym CALM (Communication Access for Land Mobiles). CALM meets the following
requirements:

Is available wherever and whenever a vehicle is present in a traffic situation

Can communicate vehicle-vehicle and vehicle-roadside in a transparent way

Relieves the applications from the need to know about communications setup and
management

Uses modern Internet techniques and standards for global usability

Provides a range of different possibilities related to data speeds, communication distance, cost
and many other parameters
CALM uses one or more media, including existing communication technologies as well as CALM specific
communication technologies.
CALM provides a layered solution that enables continuous (or quasi continuous) communications
between vehicles or between vehicles and the infrastructure. The principles of CALM architecture and
standards are predicated on the principle of making best use of the resources available: CALM uses
the optimal wireless telecommunications media that are available in any particular location, and have
the ability to switch to a different media when necessary.
CALM communication modes are defined as:
 Vehicle to Infrastructure: Communication may be initiated by either roadside or vehicle
 Vehicle to Vehicle: A low latency peer to peer network with the capability to carry safety
related data such as collision avoidance, and other services
 Infrastructure to Infrastructure: The communication system may also be used to link fixed
points where traditional cabling is unavailable
CALM Media are defined as:
 5GHz wireless LAN systems, based on IEEE 802.11 normal Wi-Fi as well as the new CALM M5
/802.11p mode
 Cellular systems, GSM/HSDSC/GPRS and 3 G UMTS
 60GHz systems
 Infrared communication
 A Convergence Layer, supporting DSRC, broadcast, positioning
CALM benefits:
 Stability: A formal body that is responsible for the development
 Openness: the standards are available to everybody
 Visibility and credibility of the specifications
 Extensibility
 Compatibility: CALM is based on Ipv6: thus fully compatible with Internet services
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
75 of 151
The CALM specifications and standards are not implementing a physical piece of equipment - CALM is
actually a set of protocols, procedures and management processes. Implementation of physical
equipment is a function of commercial related process. CALM will support multiple types of application
and multiple types of media simultaneously. It is however no requirement for implemented equipment
to support all the possible media: the choice of what media to support will be a decision of the
equipment or vehicle manufacturer, also depending on the media options that are available, varying
from country to country and from location to location.
Figure 4-20 – CALM System Overview
4.4.6. EGNOS USAGE WITHOUT SATELLITE LINK
SISNet stands for Signal in Space trough the InterNET. It is an ESA sponsored project that makes
EGNOS signals available real-time over the Internet. The major advantage is that the EGNOS signal is
available, even when EGNOS broadcast satellites are not visible, via an Internet connection.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
76 of 151
Figure 4-21 – Sisnet Architecture
SISNET allows the use of simple and cheaper GPS receivers that need not to integrate EGNOS receiver
capabilities. The complex EGNOS corrections computations are shifted from the receiver to the host
device. The price to pay is that a 1Kbps link to the Internet must be available all times. Although
suitable for today’s mobile networks, GSM/GPRS, the price to pay for this permanent link in mobile
applications may not compensate. Another view is to use SISNeT as a backup when the EGNOS
satellite signals fails. Another point to consider when using SISNeT to access EGNOS signals are the
non trivial computations and algorithms that must be performed over EGNOS data and correlated with
GPS data to provide a location. A GPS/EGNOS receiver embeds these computations that are
completely transparent to the user.
Worth to mention here is another ESA related project that may contribute to an easier integration of
SISNet capabilities, the Finish Geodesic Institute SISNeT GPS/GSM receiver. This receiver is based on
a PDA with a GSM modem and a cheap GPS PC Card receiver. All computations for position
determination are done by software running in the PDA.
4.4.7. EGNOS DATA ACCESS SYSTEM (EDAS)
The EGNOS Data Access System (EDAS) aims for fostering Multimodal Use of the EGNOS and Galileo
European navigation satellite systems, by disseminating the EGNOS products in real time and within
guaranteed performance boundaries, through alternative means to GEO satellites. EDAS development
activities have been financed by the European Commission and carried out by the European
Commission and the European Space Agency. They were funded and executed under the 6th
Framework Programme Contract. EDAS is expected to constitute the main pillar of the EGNOS
Commercial Service Provision.
EDAS (EGNOS Data Access System) is the interface point where multiple EGNOS Multimodal Service
Providers can obtain EGNOS products in real-time, within guaranteed delay, security and performance
boundaries. Service Providers can use these EGNOS products to offer end users services through
alternative means to GEO satellites. EDAS is linked to the EGNOS Master Control Facilities to get the
raw products directly from the EGNOS system. It confers the necessary security, confidentiality and
data formatting to the raw information. EDAS subsystems and interfaces are depicted in the next
Figure, covering both the components of the EDAS itself and also the interfaces with internal and
external systems (i.e. EGNOS System and the Service Providers).
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
77 of 151
Figure 4-22 – EDAS Architecture
Two main aspects summarize the importance of EDAS on the impulse to Multimodal EGNOS
applications:

Quick access to EGNOS broadcast information (NOF) through alternative means to GEO SIS
(Signal In Space).

Provision of EGNOS internal data (i.e., data not available in the NOF SIS). An outstanding
example of such pieces of information are the EGNOS Receivers (RIMS) Raw Data themselves.
Real-time high-quality GPS L1&L2, GLONASS L1 and GEO L1 measurements are available at 1
Hz rate from 67 receivers in 34 worldwide locations.
The mosaic of services that can derive from EDAS is really large, including:

Provision of SISNeT services (Note SISNeT is the precursor of EDAS, being the latter a
generalization of the ESA SISNeT concept).

Development of EGNOS pseudolites.

Provision of EGNOS services through Radio Data System (RDS).

Provision of EGNOS services through Digital Audio Broadcast (DAB).

Provision of Wide Area Real-Time Kinematics (WARTK) services, allowing obtaining decimetrelevel accuracies at continental scale.

Accurate ionospheric monitoring.

Provision of EGNOS performance information in real-time.

Archiving of EGNOS messages.

Provision of EGNOS corrections in the standard RTCM SC104 format, ready to be used by
DGPS receivers.

Provision of EGNOS receivers raw data.
4.4.8. OTHER TECHNOLOGIES SUMMARY
The technologies described in this chapter address two important problems for a road application:
ways to enforce it (in case of RUC) and ways for communication, both vehicle-to-vehicle and vehicleto-infrastructure.
From the mentioned technologies, there are some of special relevance for GINA:

GINA
ANPR – is a cost-effective solution to implement enforcement without the need to change the
OBU;
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
78 of 151

DSRC – many road tolling systems currently deployed throughout Europe use DSRC. If
possible, GINA will compare the results of GNSS with the results of a DSRC solution already
implemented.

GSM/GPRS – these are common communication technologies that are feasible to use during
GINA trials phase as the communication platform between OBUs and the central system.

EGNOS/EDAS – these are technologies important to GNSS systems since their mail goals are
to improve the accuracy of positioning data and provide integrity services, thus improving the
overall performance and reliability of any GNSS solution. In particular, the integrity service
provides guaranteed performance which enables the implementation of liability and safetycritical applications based on GNSS-only technology, such as RUC.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
79 of 151
5. END-USER REQUIREMENTS
5.1. INTRODUCTION
5.1.1. PROJECT / SYSTEM OBJECTIVES
The GINA project aims to demonstrate a GNSS-based road user charging system across the whole of
one EU country (the Netherlands). As a secondary objective, it aims to demonstrate other Value
Added Services which could be provided using the same GNSS-based infrastructure.
GINA takes as a major input for its requirements the evolving plans of the Dutch government for its
ABvM road user charging system. However, GINA is intended to inform EU wide thinking on road user
charging and is therefore not limited to the Dutch requirements. In particular, it aims to demonstrate
a variety of tariff structures, including distance-based, specific road, zone and cordon systems and
various hybrids, rather than being limited simply to the tariff system which the Dutch government will
eventually select.
It must be emphasised that GINA is a demonstration system, not a live charging system. It seeks to
demonstrate that it is possible to implement a national road user charging system from a technical
point of view. This means that it will demonstrate that:

a large number of vehicles can be fitted with appropriate On-Board Units (OBUs) and the
logistics and vehicle to OBU mapping appropriately managed

positioning data can be transmitted from the OBUs to a central system in sufficient detail and
in a sufficiently timely fashion for accurate charging to take place

the central system can process these positioning data to accurately charge vehicles according
to the trial tariffs

bills can be produced showing the charges incurred and that a level of detail can be made
available on the bills or online to allow the bills to be checked

data can be made available from the central system which would be required by the providers
of Value Added Services, by other Service Providers, by the government and by enforcement
and compliance services

Position integrity, EGNOS / Galileo (in the future) can provide added value in this approach
However, given that GINA is intended as a trial, rather than a live system, there are a number of
things which the system will not be able to demonstrate or address. In particular:

whilst the system will demonstrate the data which could be provided for interoperability
purposes, it will not demonstrate actual interoperability between multiple service providers

many operational features of a live system will not form part of the GINA project, such as
payment mechanisms, accounting systems, compliance and enforcement, communication of
tariffs to drivers through mass media, roadside signs etc.
These issues are discussed in the appropriate sections of this chapter.
The purpose of this document is to define user and functional requirements to permit the technical
design of a specific demonstration project – thus whilst the process of defining the requirements has
been informed by the thinking of varying governments / transport authorities / research bodies it does
not aim to describe all that thinking in detail; rather, it aims to document requirements which can
define a practical system.
5.1.2. END-USER DEFINITION
The EETS / CESARE road-user charging architecture identifies three sets of actors:
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
80 of 151

The toll charger (TC). This may include governments, local councils and also operators of
motorways, bridges etc. The toll charger sets tariff levels and receives revenues from the Toll
Service Provider.
In the EETS model, the TC is also responsible for compliance and
enforcement.

Toll Service Providers (TSPs). The TSP operates the system, bills individual drivers or fleet
operators and passes revenues to the TC according to the contract between the TC and the
TSP.

Service Users (SU). These include both the individual vehicle drivers and operators of fleets of
vehicles (leasing companies, car hire companies, logistics companies, employers etc.) who
carry the On-Board Unit (OBU) and pay the toll charges.
The EETS model is concerned only with road-user charging. The GINA project is also concerned with
Value Added Services of various kinds which can be provided as an adjunct to road-user charging.
For these VAS, we can categorise two groups of user:

Value Added Service Providers (VSPs). These provide services based around the location
information provided by the system. Such services include PAYD insurance, traffic information
or location based services. In practice some services might be provided directly by the main
TSP; conceptually however, the TSP is then fulfilling the role of a VSP.

Service Users (SUs). As well as the Service Users of the Road User Charging system (drivers
and fleet operators), these can include users at the government level, such as government
ministries, local councils, national and local traffic administrations which may need to receive
information about traffic and user behaviour which can be used to plan road infrastructure.
They also include Toll Chargers who require information to monitor the impact of charging
schemes on traffic / the environment and hence to refine such charging schemes; although
organisationally it is a single body, conceptually the TC is acting here as the consumer of a
VAS.
For the purposes of this document, we group the TSPs and VSPs together as Service Providers (SPs)
and the users of all RUC and VAS services together as Service Users (SUs).
Each group of actors (TC, SP, SU) will have different requirements from a road user charging / VAS
system. This document seeks to capture the requirements of all three groups.
5.1.3. KEY DESIGN PARAMETERS AND ASSUMPTIONS
Certain design parameters and assumptions will constrain what a road user charging system can
achieve. This section sets out any such assumptions. In the body of the document, the definition of
the user and functional requirements will include commentary on the impact of these assumptions.
No Map-matching
As laid out in the project proposal (Annex B, section 2.1), the GINA system will not use any map
matching at the OBU level (understanding it in a way which allows the visualization of PVT positions in
a cartography). The reasons for this are the difficulties in accurate mapping and upkeep of the map
details and the costs associated with that. The use of map-matching in the central system is a
possible consideration for some Value Added Services but the basic assumption is that GINA will
demonstrate basic road-user charging without map-matching. Although not identical, GINA is based
around the design criteria of the proposed Dutch road pricing system, where pricing is based on
distance driven within specified geo-objects; matching vehicles to roads is thus not a specific
requirement, except in limited circumstances where the geo-object can be defined as the relevant
road. The purpose of map-matching in such a system would be to ensure that variations in reported
position do not add to distance travelled and to ensure that “rogue” positions are identified and
excluded; GINA aims to demonstrate that the increased accuracy and positional integrity data of
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
81 of 151
EGNOS / Galileo and the use of appropriate processing algorithms can remove the need for mapmatching and to identify those circumstances where it remains necessary.
DSRC
The assumption set out in the GINA proposal (Annex D) was that the OBU would be GNSS only and
not incorporate DSRC for the purposes of compliance / enforcement.
Although the Dutch
government’s requirement set out in its call for tender is that DSRC is to be incorporated into the
OBU, for the purposes of the GINA demonstration project, this requirement will not be followed.
Privacy
For road-user charging systems within the EU, the privacy requirements will be rigorous, certainly
ensuring that data on individual users cannot be used for purposes for which they were not intended
and quite possibly ensuring that it is not possible to identify where and when users have been driving.
There is a trade-off between privacy requirements on the one hand and, on the other hand, what
services / functions can be provided and the complexity / cost of the system / OBU. These issues are
discussed further in section 5.3.
For the purposes of the GINA demonstration it is assumed that users have agreed to the positional
data being used in any way that the demonstration requires and specifically that positional data may
be sent from the OBU to the central system.
Security
A live operational system will require complex security throughout the system (in OBU, at interfaces
etc.). For the GINA demonstration project the GIROADS platform will be used which incorporates
security measures, including encryption. No further security developments will be carried out for the
GINA project.
Non-equipped vehicles
An operational system will need to have methods for charging vehicles which are not equipped with
OBUs, in particular, foreign vehicles. This requirement is outside the scope of the GINA project.
5.1.4. STRUCTURE OF REQUIREMENTS DOCUMENTATION
Section 5.2 first gives a high level overview of the key functional system elements of GINA and the
interaction between them and end users.
Sections 5.3 to 5.11 then document the user and functional requirements for the GINA project. These
cover:

Overall services provided by the system as a whole, involving multiple elements and users,
e.g. overall charging structure

More specific services provided by certain elements of the system, for example traffic or route
analysis

Interfaces between elements of the system and the information which flows over those
interfaces. This does not cover detailed protocols but does cover what information might need
to be exchanged and how that information might be grouped

Physical or performance requirements for specific system elements
Where relevant, the actual requirements are preceded by an overview section, discussing the issues
involved and actual experience. Summary sections are provided where appropriate; where sections of
this chapter consist entirely of formal requirement specifications, no specific summary section is
provided immediately as all formal requirements are summarised in section 5.12 (see below).
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
82 of 151
Requirements are not specifically categorised as user or functional requirements as there is a certain
overlap between them; e.g. is the requirement that users should be able to view and update personal
and account data a user or functional requirement?
Requirements are generally specified at a high level, for example, that tariffs should have multiple
time bands, rather than how many there should be or precisely what times should be covered. There
are a few exceptions, for example where billing accuracy is specified.
Each requirement is documented in the following form:
Unique identifier
User Type
Which user types are
affected by this
requirement:
Req. ID
TC – Toll Charger
SP – Service Provider
SU – Service User
Req. Type
Indicates whether this is
mandatory or optional
requirement and whether
it applies to a live system
only or to the
demonstration system as
well. See below for
clarification
Req. Category
Req. Title
Req. Description
Notes
Any clarifications of the requirement
For the requirement type, the following combinations are possible:
MD – mandatory and applies to the demonstration system; unless otherwise stated, is also mandatory
for a live system
ML – mandatory but applies only to a live system, not to the demonstration system
OL – is optional for a live system, depending on the specific requirements of the system; unless
otherwise stated is not applicable to the demonstration system
OD – could be optional or mandatory in a live system; has not yet been decided whether this will be
included in the demonstration system
All requirements which are documented in the above form are gathered together in summary tables in
section 5.12.
As indicated in section 5.1.3 above, privacy requirements can have a major impact on the ability to
provide certain services. Section 5.3 discusses privacy requirements and options in detail, including
the implications of various choices. At this stage it is uncertain which privacy requirements will be
adopted; therefore user and functional requirements whose feasibility depends on these choices have
not been eliminated – instead their dependence on privacy requirements is noted in the comments
section of each requirement.
5.1.5. METHODOLOGY
The definition of functional and user requirements has been carried out based on:

GINA
An analysis of the Dutch government’s requirements for ABvM, in so far as these are available.
The documents referenced include:
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
o
Partial Implementation Decision for Road Pricing System, 27 th June 2008
o
Implementation of road pricing system, 27th June 2008
o
Call For Tender, Kilometre Price System, version 1.0, 18th December 2008
D2.1
15/09/2009
2.0
83 of 151

A review of the experience of actual road user charging implementations around the world

Analysis of theoretical work on road user charging

A review of the documentation of other related trials, proposals and research, in particular
TfL’s Distance Based Charging Trials

Questionnaires to and discussions with ARVAL, representing the needs of Road Users

Discussions with AENOR, representing the needs of Service Providers

Analysis of transportation policies, with particular reference to the information required from
GNSS systems to support and monitor such policies
5.1.6. SUMMARY
The GINA project aims to demonstrate a GNSS-based road user charging system across the whole of
one EU country (the Netherlands), taking as a major input for its requirements the plans of the Dutch
government for its road user charging system. As a secondary objective, it aims to demonstrate other
Value Added Services which could be provided using the same GNSS-based infrastructure.
The User Requirements are based around three classes of users, based on the EETS / CESARE roaduser charging architecture:



The toll charger (TC).
Service Providers including Toll Service Providers (TSPs) identified in the EETS model and
Value-Added Service Providers (VSPs).
Service Users (SU) covering both users of RUC services and users of VAS.
The design of the GINA system will incorporate certain design parameters and assumptions:





GINA
No map-matching
No DSRC incorporated in the OBU
Users agree to positional data being used in any way that the demonstration requires and that
positional data may be sent from the OBU to the central system
The complex security requirements of a live operational system will not be developed for the
demonstration beyond those already existing in the GIROADS platform
The demonstration will not incorporate methods for charging non-equipped vehicles
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
84 of 151
5.2. SYSTEM OVERVIEW
Figure 5-1: Key system elements
Figure 5-1 above shows the key system elements involved in a GNSS road user charging / VAS
system and some of the key exchanges of data & information between them. Elements in grey are
not included in the GINA demonstration, nor are the data / information flows associated with them
included. Items in green are not included in the GINA demonstration but the data / information flows
associated with them do form part of the GINA demonstration. Data flows shown in dashed lines are
optional in a live operational system, depending on how it is specified; some form part of the GINA
demonstration, others (specifically DSRC) do not.
5.3. PRIVACY
5.3.1. OVERVIEW
For road-user charging systems within the EU, the privacy requirements will be rigorous. It will
certainly be the case that the system must ensure that data on individual users cannot be used for
purposes for which they were not intended or consented to. Although some governments may permit
the identification of where users have driven if a court order has been granted, others may specify
that it will not be technically possible to identify where and when users have been driving, even if a
court order has been granted. There is a trade-off between privacy requirements on the one hand
and, on the other hand, what services / functions can be provided and the complexity / cost of the
system / OBU.
This section discusses some of those impacts, particularly in the context of the Dutch government’s
requirements for the ABvM system. The following section then distils these into actual requirements.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
85 of 151
As a general point, it is worth noting that positional data sent from an OBU only identify the OBU. On
their own therefore such data are not truly personal data – it is only when the OBU is linked to a
vehicle or person that the data become personal.
5.3.2. IMPLICATIONS OF DUTCH REQUIREMENTS
The Dutch government’s requirements for the ABvM system are that the OBU shall only transmit to
the central system the distance driven, aggregated by tariff group. Individual positions will not be
supplied. The implications of this are:
OBU
The OBU will have to have knowledge of the tariff structure (zones, road segments, time bands,
vehicle classes etc.) although not of the actual prices for each combination. It will also need to do the
actual calculation of distance travelled within each tariff group. Hence, it will need to know what the
relevant geo-objects are, be able to identify whether individual positions are within the geo-object,
taking into account the integrity information provided by EGNOS / GALILEO and be able to calculate
distance travelled.
A relatively “thick client” or “smart” OBU will therefore be required.
If the prohibition on sending of positional data is an absolute one, then the OBU would have to
perform these types of calculations for other services as well (see below), implying multiple
applications loaded onto the OBU to support multiple services.
This could potentially create
performance issues, but more importantly, could potentially lead to software stability issues, with the
interaction of the different applications.
Services provided
If only aggregated data can be sent to the central system, it will not be possible for users to check
their bills. This could be overcome by users specifically opting to have detailed positioning data sent
to the central system; however, the central system would then have to carry out the same processing
as the OBU has already done in order to relate those data to the bill. In addition, once the detailed
positioning data are in the central system it would then be technically, if not legally, possible to track
the movements of an individual vehicle. An intermediate option of sending only entry and exit points
is possible; this is detailed in requirement OF-23 in section 5.7.2.4 below.
It will also not be possible to provide services such as route analysis, which rely on the analysis of
details of journeys of large numbers of vehicles. There are a number of ways in which this could be
overcome. Users could elect to provide their detailed positional information for this purpose; the
possibility of tracking referred to above remains and, because of this, sufficiently large numbers may
not agree to provide the volume of data to make the service viable. It should be noted however that,
in general, only a sample of users would need to provide positioning data – the size of the sample
would depend on the nature of the service and the size of the relevant population. Alternatively, the
id of the OBU could be anonymised in various ways; however, the id of the sending SIM in the OBU
could then theoretically be used to tie together the anonymised information with the true identity.
Services such as PAYD insurance would be less problematic, in that the user could consent to the use
of positional data and the OBU could send the positional data directly to the service provider
concerned (i.e. not the central system for road user charging).
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
86 of 151
OBU-Central System Communications
There would be a need to periodically update tariff groups, geo-objects in the OBU. This would also
apply to configuration data required for other services. Whilst this facility would be infrequently used
it does needs to be present.
An absolute prohibition on sending detailed positional data from the OBU and sending data aggregated
by tariff group would reduce overall traffic volumes. If, however, positional data were sent to each SP
separately then this could potentially increase overall traffic volumes significantly. For the GINA
demonstration, the central system would act as both TSP and VSP and there would not therefore be a
requirement for multiple sending of positional data.
5.3.3. PRIVACY REQUIREMENTS
This section includes overall privacy requirements. Specific requirements arising out of these are
covered in the appropriate section (e.g. what data an OBU may send is covered under OBU
requirements).
Req. ID
Req. Category
PR-1
User Type
TC, SP, SU
Privacy
Req. Type
Mandatory, Demonstration
Mandatory, Live
Req. Title
Data Protection
Req. Description
No personal data or information from a GNSS road user charging system shall
be used for purposes other than those specified by law or those which users
have specifically agreed that they may be used for
Notes
This would be the minimum requirement for any EU road user charging
system. Some jurisdictions might impose tougher regulations. Purposes
specified by law could include access to personal data by security services
under a court order. For the purposes of the GINA demonstration, end users
would be required to agree to the use of their location data as dictated by the
needs of the project
Req. ID
PR-2
User Type
SP, SU
Req. Category
Privacy
Req. Type
Mandatory, Demonstration
Req. Title
Security of personal data in the GINA demonstration
Req. Description
All personal data gathered in the course of the GINA demonstration shall be
kept securely, shall not be distributed outside the confines of the project and
shall be destroyed at the end of the project.
Notes
Personal data does not include data just identifying the OBU, provided that
the OBU id cannot be linked to an individual
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
87 of 151
Req. ID
PR-3
User Type
TC, SP, SU
Req. Category
Privacy
Req. Type
Optional, Live
Req. Title
No detailed location data
Req. Description
It shall not be technically possible for the location of an individual user or
their journey details to be determined either in real-time or retrospectively
Notes
This is a stronger version of PR-1 and is the requirement of the Dutch ABvM
system
Req. ID
PR-4
User Type
SP, SU
Req. Category
Privacy
Req. Type
Optional, Live
Req. Title
Opt-in for location data for general services
Req. Description
Road users may elect to have their location data collected and used for the
purpose of general services which rely on the analysis of detailed location
data of large numbers of road users. The arrangements for the collection and
processing of data in these circumstances shall be such as to make the
location of an individual user or their journey details as technically difficult as
is consistent with the provision of the service
Notes
Only applicable if PR-3 is a requirement
Req. ID
PR-5
User Type
SP, SU
Req. Category
Privacy
Req. Type
Mandatory, Live
Req. Title
Opt-in for location data for individual services
Req. Description
Road users may elect to have their location data collected and used for the
purpose of the provision of services to them which rely on the analysis of
their detailed location data.
Notes
VAS Providers (VSPs) require similar data to that required by the main Toll Service Provider, namely
positional data for individual vehicles which can be matched to relevant geo-objects, maps, charge
tables etc. These data could be obtained by the OBU sending required data direct to the VSP or by
the TSP receiving all data from the OBU and passing relevant data to the VSP.
The former has the advantages of:

ensuring that precisely the data required is delivered to the VSP

ensuring that the TSP receives only data that it requires (e.g. if privacy requirements mean
that the TSP should have no knowledge of vehicles’ positions but users are allowed to sign up
to additional VAS where their positions are known, then the latter approach would mean the
TSP handled data it did not require)

not introducing an intermediary which could potentially delay or distort data
Conversely the latter approach has the advantages of:

Not adding duplicate communications traffic to the OBU wireless interface

Ensuring that sensitive data are filtered by a trusted entity (the TSP) so that tighter controls
can be imposed on those data
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
88 of 151
The approach will vary from implementation to implementation. Assuming that data are passed to the
VSP via the TSP, this section considers at a high level what that interface should be. For the purposes
of the GINA project, where both TSP and VSP functions will be provided on the GIROADS platform,
this is an internal interface and is therefore not specified in detail at this stage. For an external
interface, the information content will be defined by the user requirements of the VAS; however, there
are some overall privacy requirements which can be specified for that interface.
Req. ID
PR-6
User Type
SP, SU
Req. Category
Privacy
Req. Type
Mandatory, Live
Req. Title
Limitations of data passed from TSP to VSP
Where positional data for individual vehicles is passed from TSP to VSP the
minimum amount of data shall be supplied to allow the VAS to be supplied.
In particular:
Req. Description

By default, the vehicle information shall be limited to just vehicle class
and emissions class.

If identification of a specific vehicle is required (e.g. to allow origindestination analysis) then the id of the OBU shall be anonymised (e.g. by
means of a hash algorithm) and the parameters of the anonymisation
method shall be changed daily so that the same OBU id will not map onto
the same anonymised id

Passing the actual OBU and vehicle ids shall be subject to requirements
PR-4 and PR-5
Notes
5.3.4. SUMMARY
For road-user charging systems within the EU, the privacy requirements will be rigorous but may vary
from country to country. There is a trade-off between privacy requirements on the one hand and, on
the other hand, what services / functions can be provided and the complexity / cost of the system /
OBU. The Dutch government’s requirements for the ABvM system are that the OBU shall only
transmit to the central system the distance driven, aggregated by tariff group. Individual positions
will not be supplied. The implications of this are:

A relatively intelligent OBU will be required as it will need to have knowledge of the tariff
structures and relevant geo-objects and to calculate distances travelled. If the OBU needs to
carry out these calculations for other services, implying multiple applications, this could
potentially lead to performance and software stability issues.

It will not be possible for users to check their bills.

It will also not be possible to provide services such as route analysis, which rely on the
analysis of details of journeys of large numbers of vehicles.

Services such as PAYD insurance would be less problematic, in that the user could consent to
the use of positional data and the OBU could send the positional data directly to the service
provider concerned (i.e. not the central system for road user charging).

There would be a need to periodically update tariff groups, geo-objects in the OBU.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
89 of 151
5.4. SERVICES
5.4.1. INTRODUCTION
For the purposes of this document, we have divided the services which can be provided by a GNSSbased RUC system into two groups:

Road User Charging services – i.e. the structure(s) of charges that can be applied for the use
of roads

Value Added Services – i.e. additional services which can be supported by the infrastructure
which is put into place primarily for RUC services
These VAS can further be considered in two groups:

Aggregated VAS, which rely on the analysis of data about road use by large number of road
users and

Specific VAS, which are dependent on the road use by or current location of a specific road
user
A separate section sets out the user requirements for each of these three groups of services (RUC,
aggregated VAS and specific VAS), preceded, where applicable, by a section giving the overall context
for these services.
5.4.2. ROAD USER CHARGING - OVERVIEW
This section is a general analysis of road pricing tariff structures and their requirements. Although a
number of these tariff structures cannot be fully supported by GNSS based systems (i.e. further data
inputs are required), they have been included in this analysis to provide context.
Measures of value pricing are a reaction to the increasing congestion of traffic infrastructures, mostly
found around urban areas and their access roads. The measures included in this document focus on
the idea that the user should be charged according to the social marginal cost (in the short term and
varying depending on congestion) that his use of the road implies.
The result of implementing value pricing measures allows agencies in charge of mobility management
to regulate not only the use of the roads but also the way people travel (destination, transport mode,
travel time, route and even the number of users per vehicle). Figure 5-2 below shows how these
measure can focus on the use of the road, the vehicle or the features of the parking zones; the rest of
this section concentrates on the first two of these, based on the road pricing.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
90 of 151
C arrilelanes
s de alta
HOV
o cu pa c ión
Variable
tollle s
P ea je s va riab
Infraestru ctu ra s
Infrastructures
C a rrile
s rá pIntertwined
ido s y n o rm ale
s en tre c ru za do s
Fast
and
Regular
(FAIR) Lanes(F A IR L an e s)
R a cion am ie n to de l e s pa cio
Road
space rationing
Tariff
byn the
T a rifació
p o r use
u so dof
e
ca
rreteras
the road
C o rd ón
Cordon
Zona
Zone
T iem p o
Time
D e m o ra s
Delays
D is ta n c ia
Distances
Tariff
T a rifac
in ión
one
e n point
un p u n to
R e des
Networks
TTariff
a rifa ció
en
inn an
un
á rea
area
T arifa c ió n
C
om bin a c ió n
Combination
Complex
tariff
c om p le ja
Value
pricing
M e d id
as de
vmeasures
a lu ep ric in g
via rio
S e gu ro s seaccording
g ún la d is ta n cto
ia the
re co rrid
a
Insurance
driving
distance
TTariff
a rifa ció
n p
o r uuse
so dof
el
by
the
ve h íc ulo
the vehicle
Taxes
Im p ueand
s to s yrental
a lqu ile rprices
seg ú n eaccording
l nú m e ro de with
k iló m ethe
tro s travel distances
C o che c o m p artid o (ca rs ha rin g)
Carsharing
T a rifa
n duse
el of
Tariff
byció
the
es ta cio n a m ie n to
the parking
E s ta cio na
ie n to s a ca mfor
b io de
d in e ro
Parking
inmexchange
money
Z o na s d e e sparking
ta c io na m zones
ien to re g u la da s
Regulated
F u e n te -: S a la s (2 0 0 8 )
Source: Salas (2008)
Figure 5-2: Structure of value pricing measures (Source: Salas, 2008)
5.4.2.1. Tariffing by road use
This way of fixing the payment for the use of the road is a method that encourages the inclusion of
the external costs in the amount of money that is charged to road system users, since this is a limited
and valuable resource.
Measure
Description
Experiences
Interstate 15 Express Lanes
HOV
Lanes
HOV lanes, a strategy focused on congestion
management, consists of the disposition of a lane
only for high occupancy vehicles (over 2 or 3
passengers), who can use it for free or by paying a
special fare.
HOT
Lanes
• Free use for vehicles with 2
or more passengers
• No
charge
for
vehicles
running on clean energy
HOT (High Occupancy Toll) lanes are HOV
lanes which can also be used by vehicles with a
single user (the driver), but only by paying a
higher tariff. HOT lanes are used where the
number of vehicles with multiple passengers is too
small to justify a lane being dedicated just to their
use.
This measure can be applied using segregated
lanes, with a clear separation from the rest of the
flow and limited access and exit points, or virtually
separate lanes where a barrier is not required.
Variable
GINA
The use of a specific road, tunnel or bridge is
GNSS for INnovative road Applications
SR 91 Express Lanes:
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
91 of 151
Measure
Description
Experiences
Toll
charged differently depending on the day or
the hour: for instance, on a week day and during
the peak hour the cost for using a frequently-used
road is higher.
10 miles with 2 lanes each way
and variables tolls by the time slot
with discounts offered for high
occupancy vehicles. The fare is
notified, in real time, to the users
by variable messages on the road
or through email.
(Time
slots)
By discouraging part of the vehicle flow, users are
benefited, since the delay time is reduced.
The Golden Gate bridge:
Variable charging only for vehicles
heading for San Francisco, with a
price variation according to the
category
of
the
vehicle
(motorcycles, two axis and more
than two axis vehicles, carpools,
hybrids vehicles).
FAIR Lane
The introduction of FAIR (Fast and Intertwined
Regular) lanes on the road network is based on
the concept of a dynamic tariff in which some
lanes of the road, separated from the rest of the
lanes, allow the user to travel at a free flow
speed. This is achieved by charging a tariff
regulated by a variable price established
according to the number of users getting into
these lanes, i.e., if the density of vehicles in this
lane reaches a level at which the speed is less
than the one reached at free flow, the price for the
use of this lane increases in order to discourage
the entrance of new vehicles to the FAIR lane.
The economic benefits obtained from the
implementation of these exclusive fast lanes (the
money collected from the users that travel trough
them) are reinvested in the same transport
system.
Measure
Road
Space
Rationing
One Point
GINA
San Diego I-15 FasTrak:
With 8 miles and 2 reversible lanes
this system of dynamic variable
tolls ensures free-flow driving
conditions.
I-580 / I-680 FAIR Lanes
Study – Alameda County,
California
This project, that investigates the
potential for implementing the new
Fast and Intertwined Regular
(FAIR) lanes concept along two
East
Bay
corridors,
will
be
coordinated with the concurrent
“I-680
Smart
Carpool
Lane
Project” study.
Description
Experiences
This is a scheme that accomplishes a rational use
of the road during peak hours by means of a credit
system of neutral collection.
The tariff policy
based on Credit Base Congestion Pricing
(CBCP) consists of a personal monthly
allowance of monetary travel credits to use
on the roads. The money to buy the right of
circulation depends, not only on the day and the
road type, but also on the demand on this
infrastructure
and
its
associated
relative
externalities.
This last attribute makes the
interchange system similar to the stock market: if
a user requires more credit he can buy it; owners
of credit can either retain it for later use or sell it
in exchange for money; the price of credit will
therefore be set by the level of supply and
demand in the market.
Not yet implemented
This kind of road charging can be implemented in
GNSS for INnovative road Applications
Singapore
(1975):
Area
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
92 of 151
Measure
Description
Experiences
Tariff
just one location, along a cordon or in an area,
according to the restrictions suitable for the
travels modifications to be introduced.
Licensing Scheme, replaced by
Electronic Road Pricing (ERP) in
1998.
•
One location: Flat fare to use a specific road is
the classical application of the toll tariff.
Cordon: Flat fare to travel from one area to
another,
that
could
be
unidirectional
or
bidirectional.
•
Area licensing scheme: Fare to use the road
network inside a specific area irrespective of the
length or distance of the trip. This tariff structure
could control the access in the regulated zone all
day long or during specific periods like peak hours.
Depending on policy objectives, this system can
collect money either just from vehicles in motion
or also form stationary vehicles (e.g. parked
vehices).
London
(2003)
Variations of one-point tariffs include aspects
associated to the trip, such as travel distance,
the length of the trip or time delays (e.g. extra
time due to queues on specific road segments at
specific times of the day).
Mixed
Tariff
•
Pioneer in the introduction
of the urban tariff
Restriction
of
the
circulation in peak hours in
the central district
The
toll
cost
varies
according to the average
speed on the network.
Tariff structures which employ a combination of
the schemes set out above are called complex
configuration. Since such a mixture aims for a
better adjustment of the tariff structure, the
particularities of its implementation depend on the
features of the network.
•
•
•
•
•
•
Congestion
Charging
Discount
for
residents,
taxis, minibuses and no
charge
for
emergency
vehicles
15% Demand reduction
30% Congestion reduction
Reliability increase
12% Reduction of the
pollution
Net
revenues
of
£90
million in 2004 and £122
million
in
2005
(fee
increase from £5 to £8 in
2005)
Not yet implemented
5.4.2.2. Tariffing by vehicle use – pay as you drive
The concept of value pricing also includes measures focused on the rationalisation of the use of
vehicles, which influences and reduces fuel consumption, pollution, congestion and the number of
accidents in the network. This structure is also known as PAYD “Pay As You Drive”.
Measure
Description
Experiences
Insurance
according
to
travel
distance
One way to implement a PAYD structure is via
insurance cost. Through this, the owner of the
vehicle pays an insurance premium according
to the number of kilometres travelled, which
clearly encourages the limited use of private
vehicles.
England's
Norwich
Union
Insurance: in 2003 started to
offer PAYD insurance policies PAYD
to a limited base of drivers.
Other parameters can be considered for the
implementation of a PAYD insurance scheme (e.g.
type of road, driving profile etc.) so complex
schemes for the implementation of this type of
insurance are also possible.
GINA
GNSS for INnovative road Applications
Mapfre
Insurance
Company
(Spain): In 2009 the YCar
program was launched by which
young people could enjoy a
reduction of up to 65% of
premiums and up to 600 € in
prepaid fuel cards, incentives that
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Measure
Description
D2.1
15/09/2009
2.0
93 of 151
Experiences
are granted in agreement on how
they drive: the kilometres driven
in the car, the speed and if there is
night driving.
Taxes and
rental
prices
according
to
the
travel
distance
The idea of fixing taxes and the price to rent a
car including a component in the charge
depending on the distance travelled is an
interesting variation of PAYD. In this system it is
important to consider that the fixed costs are over
80% of the total amount required to buy and
maintain a car. This is a concept that can be also
implemented in car leasing (in the United States
30% of new cars are bought via leasing).
Oregon (USA): During 2007, a
year-long experiment took place
that
tested
a
system
that
eventually could replace the state
gas tax with a road-user fee. This
test used volunteers on vehicles
equipped
with
elements
to
measure the amount of miles they
drove; when they refuelled up, the
drivers paid for their petrol as well
as 1.2 cents for each mile driven
since their last fill-up; they did not
pay the 24-cents-a-gallon state
petrol tax.
Carsharing
Carsharing is a method that allows people to
use cars without owning them, which turns
fixed costs into a variable cost and can therefore
provide a great benefit to several people.
Milan, Italy (2001)
The requirements for these systems indicate that
they must be placed in locations near the
residential areas and under reasonable tariffs that
are also convenient for short trips.
With an MCS card the users get a
personal code that allows them to
make a reservation, choose the
car and the garage to pick the car
up and deliver it. The monthly
charge is based on the distance
driven by each client.
• Annual membership: between
70 and 100 euros.
• The hourly rate is 1.80 euros
from 7:00 to 24:00 (it is free
between 24:00 and 7:00) and
the cost per km is 0, 32 euros
per km, including the fuel.
• For the ones who drive under
10,000 kilometres in a year, the
use of the MCS system is 4,000
€ cheaper per year than owning
a car.
5.4.2.3. Tariff structure information requirements
The table below sets out in generalised form the information required to support the various tariff
approaches discussed in sections 5.4.2.1 and 5.4.2.2 above, whether required by tariff service
providers or by service users and indicates whether the information requirements can be supported by
GNSS-based systems.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Information
When
Identification of a new user of the
regulated lane or area and his
position.
At the moment of
access to the regulated
lane or area.
Registering and sending the
charge or fine to the user or
offender.
During use of the lane
or area.
Sending of data required to build
a data base of the users of the
regulated lane or area: number of
users annually and the average
number of vehicles during
different time periods.
During the use of the
lane or area, or
periodically depending
on specific use
Identification of registered
commuter who travels regularly in
the lanes or area.
At the moment that
the user gets into the
regulated lane or area.
Information about the toll cost.
At the moment that
the user gets into the
regulated lane or area.
Supported
by GNSS?
D2.1
15/09/2009
2.0
94 of 151
Required by which
tariff
Yes
(in principle,
but lane level
accuracy may
not be
achievable at
present)
Yes
All
(Except
Pay as you drive)
All
(Except HOV Lanes
and
Pay as you drive)
The number of passengers.
During the use of the
lane or area.
No
Access to the credit market.
After the trip.
No
Deduction of credit (CBCP) from
account
At the moment of
access to the regulated
area.
Register and sending the amount
of kilometres driven by the user
and the charge.
At the end of the trip
or after a specific
accumulative period
(like every six month
or a year)
HOV Lanes
Road Space Rationing
Yes
Yes
Pay as you Drive
Sending of the data required to
build a data base of the amount
of kilometres driven by the users.
The information about the general
payment policy structure.
After the
establishment of the
policy
No
5.4.3. ROAD USER CHARGING - SUMMARY
The above analysis of information requirements of different tariff approaches indicates that, in
principle, GNSS can support a wide variety of tariff approaches, although in some cases other data
would be required and in some cases the level of precision required (e.g. lane level usage) may
suggest that other approaches might, in practice, be more appropriate.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
95 of 151
5.4.4. ROAD USER CHARGING - REQUIREMENTS
As discussed in section 5.4.2 above, there are many different ways of charging for the use of roads;
the current position of the Dutch government in respect of its ABvM system is to charge per km with a
supplement per km at peak times, with the rate varying by vehicle / congestion class. Although the
requirements of the GINA system are based around the requirements of the Dutch ABvM system, the
GINA project is intended to inform discussion on GNSS-based road user charging in the whole of the
EU. Thus, the charging requirements need to encompass a variety of schemes.
Req. ID
Req. Category
CH-1
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Per kilometre charge
Req. Description
It shall be possible to charge vehicles per kilometre driven
Notes
Req. ID
Req. Category
CH-2
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Variation in per kilometre charge by location
Req. Description
It shall be possible to vary the per kilometre charge by area
Notes
This could be as simple as a default charge for non-specified areas and a
single charge for all specified areas (e.g. rural versus urban). It could also
allow for a number of different charges for different areas
Req. ID
CH-3
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Req. Category
Optional, Live
Req. Title
Variation in per kilometre charge by specific road
Req. Description
It shall be possible to vary the per kilometre charge by specific road
Notes
Without map-matching, this requirement implies defining each road (or road
segment) as a separate geo-object
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Req. ID
Req. Category
D2.1
15/09/2009
2.0
96 of 151
CH-4
User Type
TC, SP, SU
Charging
Req. Type
Optional, Demonstration
Optional, Live
Req. Title
Variation in per kilometre charge by specific road class
Req. Description
It shall be possible to vary the per kilometre charge by road class
Notes
Typically road class would be defined according to the relevant national road
classification system (e.g. motorway, dual-carriageway o major road, singlecarriageway major road, secondary road, minor road etc.) and this
requirement would normally be met using map matching; without mapmatching, individual roads would need to be defined as separate geo-objects
and appropriately classified
Req. ID
CH-5
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Req. Category
Optional, Live
Req. Title
Cordon charge
Req. Description
It shall be possible to charge for entering or exiting a specific area or road (a
cordon charge)
Notes
Charging a flat fee for using a specific road or road segment is effectively a
specific form of cordon charge
Req. ID
CH-6
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Req. Category
Optional, Live
Req. Title
Cordon charge variation by direction
Req. Description
It shall be possible for a cordon charge to be different for opposing directions
of travel, including having one direction charged at zero.
Notes
Req. ID
Req. Category
CH-7
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Area charge
Req. Description
It shall be possible to apply a flat charge for driving within a specific area or
on a specific road, whether or not the boundary defining that area or road has
been crossed
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Req. ID
Req. Category
D2.1
15/09/2009
2.0
97 of 151
CH-8
User Type
TC, SP, SU
Charging
Req. Type
Optional, Demonstration
Optional, Live
Req. Title
Private property exemption
Req. Description
It shall be possible to exclude private property from charges
Notes
This could include either individual private roads or whole areas, e.g. private
parks, hospitals etc. Such a requirement has a high cost in defining and
maintaining the boundaries of the private property. The information currently
available on the Dutch ABvM system does not indicate any intent to exclude
private property.
Req. ID
CH-9
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Req. Category
Optional, Live
Req. Title
Time of day charging
Req. Description
It shall be possible for charges to vary by time of day / day of the week
Notes
Req. ID
Req. Category
CH-10
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Time of day charging variation by location
Req. Description
It shall be possible for time bands of charges to be different for different
locations
Notes
Req. ID
Req. Category
CH-11
User Type
TC, SP, SU
Charging
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Vehicles / emissions class charging
Req. Description
It shall be possible for charges to vary by vehicle class / emissions class
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Req. ID
Req. Category
D2.1
15/09/2009
2.0
98 of 151
CH-12
User Type
TC, SP, SU
Charging
Req. Type
Optional, Demonstration
Optional, Live
Req. Title
Vehicle and vehicle class exemption
Req. Description
It shall be possible for specific vehicles and vehicle classes to be exempt from
charges
Notes
Req. ID
Req. Category
CH-13
User Type
TC, SP, SU
Charging
Req. Type
Optional, Demonstration
Optional, Live
Req. Title
Individual exemption
Req. Description
It shall be possible for specific individuals to be exempt from charges
Notes
This category could include diplomats or disabled drivers / passengers; the
exemption would be personal and would override the charging category of the
vehicle
Req. ID
CH-14
User Type
TC, SP, SU
Req. Category
Charging
Req. Type
Mandatory, Demonstration
Req. Title
Charge type combination
Req. Description
It shall be possible for any combination of requirements CH-1 to CH-13 to be
applied simultaneously
Notes
Req. ID
CH-15
User Type
TC, SP, SU
Req. Category
Charging
Req. Type
Optional, Demonstration
Req. Title
Dynamic charging
Req. Description
It shall be possible for charges to vary dynamically
Notes
Normally charges would be set periodically (e.g. once a year). It is however
possible for the central system to monitor traffic behaviour and to vary
charges dynamically according to that behaviour
5.4.5. VALUE-ADDED SERVICES - PAY AS YOU DRIVE - REQUIREMENTS
So-called “pay as you drive” services, such as vehicle insurance, where users are charged according to
where, when and how they drive would have similar structures to road user charging; however, they
would be unlikely to include cordon or area charging. Conversely, pay as you drive charging would
probably be by both vehicle class and individual driver and might include factors such as speed and
acceleration.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
99 of 151
Req. ID
PY-1
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Per kilometre charge
Req. Description
It shall be possible to charge vehicles per kilometre driven
Optional, Live
Notes
Req. ID
PY-2
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Variation in per kilometre charge by location
Req. Description
It shall be possible to vary the per kilometre charge by area
Notes
This could be as simple as a default charge for non-specified areas and a
single charge for all specified areas (e.g. rural versus urban). It could also
allow for a number of different charges for different areas
Req. ID
PY-3
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Variation in per kilometre charge by specific road
Req. Description
It shall be possible to vary the per kilometre charge by specific road
Notes
See notes to CH-3
Req. ID
PY-4
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Variation in per kilometre charge by specific road class
Req. Description
It shall be possible to vary the per kilometre charge by specific road class
Notes
See notes to CH-4
GINA
Optional, Live
Optional, Live
GNSS for INnovative road Applications
Optional, Live
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
100 of 151
Req. ID
PY-5
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Private property exemption
Req. Description
It shall be possible to exclude private property from charges
Notes
This could include either individual private roads or whole areas, e.g. private
parks. Such a requirement has a high cost in defining and maintaining the
boundaries of the private property
Req. ID
PY-6
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Time of day charging
Req. Description
It shall be possible for charges to vary by time of day / day of the week
Optional, Live
Optional, Live
Notes
Req. ID
PY-7
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Time of day charging variation by location
Req. Description
It shall be possible for time bands of charges to be different for different
locations
Optional, Live
Notes
Req. ID
PY-8
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Vehicle charging
Req. Description
It shall be possible for charges to vary by specific vehicle
Notes
Typically insurance rates would vary by individual vehicle, according to
model, make, age, mileage etc.
GINA
GNSS for INnovative road Applications
Optional, Live
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
101 of 151
Req. ID
PY-9
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Mandatory, Demonstration
Req. Title
Individual charging
Req. Description
It shall be possible for charges to vary by specific individual
Notes
Typically insurance rates would vary by individual according to age,
experience, accident record etc
Req. ID
PY-10
User Type
SP, SU
Req. Category
Pay as you drive
charging
Req. Type
Optional, Demonstration
Req. Title
Driving style charging
Req. Description
It shall be possible for charges to vary according to driving style
Notes
It is conceivable that insurers may wish to vary charges according to driving
style (e.g. typical speeds, exceeding speed limits, acceleration / braking etc.
Req. ID
PY-11
User Type
Req. Category
Pay as you drive
charging
Req. Type
Req. Title
Charge type combination
Req. Description
It shall be possible for any combination of requirements PY-1 to PY-10 to be
applied simultaneously
Optional, Live
Optional, Live
G, SP, EU
Mandatory, Demonstration
Notes
5.4.6. VALUE-ADDED SERVICES - AGGREGATE SERVICES - OVERVIEW
5.4.6.1. Introduction
This class of services depends on the analysis of the journeys and position data of a large volume of
vehicles in order to establish current and historic traffic flows. Such services might include:

Up to date traffic flow information

Best route planning according to various criteria (time, low CO2 emissions) based on either
current or historical traffic flows
Included in this category are services of this type provided to the Toll Charging category of actors or
to the government or state level of users. These might include:

Traffic flows analysed by vehicle or emission category to allow the planning of new roads or
tariffs

Traffic flows analysed by tariff to allow the analysis of the effects of road user charging and
the planning of new tariffs

Traffic flows analysed by driver behaviour (bunching, acceleration, speed) to allow the
identification of potential accident blackspots
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
102 of 151
Although the types of services which could be provided to actors at the state / TC level are
conceptually very similar to those provided to general road users, as these actors form a specific and
very important category, their needs are covered in some detail in this section. Policies and strategies
are discussed first and then the information needed to support those strategies.
5.4.6.2. Government / TC policies and strategies
Every government can set a large number of policies depending on its needs, particularly related to
transport management. There are some general objectives shared by the vast majority of them, but
all of them can be summarised in just one idea, to reduce transport negative externalities so as to
make transport more sustainable.
The most representative policy areas are listed below, describing what their particular objectives are
and how they could be implemented.
- Reducing environmental/health effects
This set of objectives deals with reducing air pollution, noise, and the amount of greenhouse gas
emissions causing climate change. This can be achieved in many ways, such as reducing vehicle
travelled miles growth, transition to more ecological fuels and improving vehicle technologies.
From the infrastructural point of view this can only be tackled by reducing congestion.
- Improving road safety
Improving road safety is particularly affected by infrastructure design and how easily users can
read it and adapt their behaviour to prevailing conditions. This set of objectives therefore sets out
to affect users’ behavior, adapting it to the optimal one required by changing conditions (traffic
flow, weather etc) in order to reduce accident rates and diminish the seriousness of injuries.
- Improving Economy and social welfare
Productivity, a key factor in economic growth, is in turn critically affected by speed and security of
travel over road infrastructure. Transport management objectives in this area focus on applying
measures to reduce travel time delays.
- Improving Accessibility and integration
This set of objectives is related to the preceding ones. By means of increased accessibility and
transport integration, governments can reduce transport costs and therefore increase productivity,
they can modify modal mix by relieving congestion, reducing pollution and even reducing traffic
accidents.
These objectives can be achieved by a variety of strategies. Many combinations can lead to the same
result, with different implications. Figure 5-3 below summarises the research on the relevant impacts
of some strategies on different policies.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
103 of 151
Figure 5-3: Qualitative impact of different measure on different policies (Kocak, 2002) †
†
(Kocak, 2002) Road User Charging : Tools for option generation to increase acceptability
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
104 of 151
Reducing congestion is a major factor in reducing negative externalities and travel time delays and
thus is a common denominator for major impact strategies. These kinds of strategies are intimately
related to traffic demand management by means of road charging, trying to modify user travel
behaviour, inducing a more optimal modal split, departure time or route choice. These initiatives need
a specific effort to provide the user with the right information at the right time.
Another relevant class of strategies is related to incident management, relieving car crashes and
communicating traffic status to users in order to induce the correct route choices to achieve optimal
infrastructure efficiency.
Based on that concept, we focus on the government’s information needs by means of the different
variables which need to be measured in order to apply the following strategies listed for every policy
previously defined. This is not an exhaustive list, but it contains the main ideas to show which
relevant variables (that will be defined later on) are the ones that define common strategies and
measures to be implemented.
Policy Area
Strategies
Measures
Environmental /
Health
 Travel Demand Management
 Reducing global travel distance
 Internalisation of transport
externalities
 Changing modal split
 Promoting homogeneous speed
(reducing stop & go situations)
 Increasing private transport costs
 Reducing public transport costs
Road Safety
 Reducing deaths and injuries
 Reducing incident risks
 Promoting appropriate driving
behaviour (fine offenders)
 Promoting homogeneous speed
(reducing speed differences and
braiding)
 Specialised corridors / time windows for
HGV (applying toll discount)
 Driver rest time control
 Speed control
 Promoting driver education
 Promoting insurance discounts in young
drivers driving out of hazardous time
periods or conditions
Economy /
Welfare
 Promoting transport efficiency
 Internalisation of transport
externalities
 Raise revenue for transportation
projects
 Transport project appraisal for
efficient funds allocation
 Reducing transport costs and
externalities
 Road space rotating (CBCP – Credit
Based Congestion Pricing)
 FAIR (Fast And Intertwined Regular)
Lanes
 Efficient origin-destination information
Accessibility /
Integration
 Promoting low access cost for
public transport network
 Promoting lower public transport
costs
 Promoting multi-modal trips
 Promoting new modal split
 Public transport priority
 Promoting HOV and HOT lanes
5.4.6.3. INFORMATION REQUIREMENTS
This section discusses the different variables to be measured by a GNSS Road Charging system in
order to provide the government or TC with sufficient decision tools for better transport policymaking
related to the strategies and measures discussed above.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
105 of 151
First of all, we found necessary to make some comments from a general point of view on the
application of a GNSS system in order to contextualize our analysis. After this we will list the vehicle
information requirements in order to apply the measures described, focusing on the theoretical
feasibility to acquire it using the GNSS architecture. And finally, we will analyze the information
requirements from a planning point of view.
GNSS Characteristics
Any vehicle positioning system will work with two main variables, time and position (according to a
global reference system) detected and transmitted by means of an OBU aided by a GNSS receiver; in
most cases, to provide the information required, these positions must be related to specific road
sections defined and previously recorded either in the OBU or in the back-office system. Every
variable discussed below is defined by a set of operations on a sequence of data points involving time
and position.
In addition, where data are measured is as important as the definition of the variable being
calculated, in order to correctly describe the phenomena the variable is trying to characterise. Even
where continuous vehicle tracking is not possible (this may not be an option due to privacy concerns
or the problems of management of large data volumes), it may be possible to achieve the desired
ends by means of a discrete approach. Roads can be seen as a collection of homogeneous sections
that share the same fundamental characteristics, and data collection could be restricted to
representative sections. Clearly, it will be basic for any GNSS application to correctly characterise the
road.
Vehicle Information Requirements
The following table shows the main information which could be collected from a GNSS-based RUC
system and what measures and policy objectives that information could support.
Information
Description
Characteristics
Measures
Policy Areas
Vehicle type
Key vehicle
characteristics
Vehicle
Allows implementation of:
 Environmental /
health
 Class
 Dimensions and
weight
 Owner’s data
 Emissions class
 Specialized corridors for specific
vehicle classes
 Road safety
 Driving behaviour enforcement
for specific vehicle classes
 Fining offenders through owner’s
data
 Specific toll rates for low
emissions vehicles
 Insurance bonuses related to
driving behaviour
Velocity
First derivative
wrt time of
vehicle
trajectory
(speed and
direction)
 Instant velocity
Allows implementation of:
 Spatial velocity
(i.e. over time)
 Controlling driver behaviour
 Environmental /
health
 Assisting driver with warning
messages and alerting police
patrols if required
 Economy /
welfare
 Road safety
 Accident reconstruction as a
service for insurance companies
and lawsuit support
 Emissions calculations for
environmental policies
management
 Homogenous velocity
enforcement by means of
advanced VSL
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
106 of 151
Information
Description
Characteristics
Measures
Policy Areas
Acceleration
Second
derivative wrt
time of vehicle
trajectory
Ability to determine
vehicle trajectory
with sufficient
precision to detect
acceleration /
deceleration which
is out of the
capability range of
the vehicle’s
brakes; minimum
of 1m/s2
Allows implementation of:
 Environmental /
health
 Remote crash detection
 Emergency patrol management
(reduced reaction time)
 Warning messages to other
drivers on same route
 Improved emissions calculations
(stop & go congestion has major
impact on emissions)
Gap (security
distance)
Distance
between rear of
one vehicle and
front of following
one
Requires knowledge
of vehicle length
and position of ALL
vehicles
Allows implementation of:
Origin Destination
Start and end of
every travel
stage of vehicle
Ability to detect
start / end of
journey by means
of signal associated
with engine start.
Allows implementation of:
Travel time
Traffic
density
Traffic
intensity
GINA
 Road safety
 Road safety
 Controlling driver behaviour
(especially at specific hazardous
points such as tunnels or
bottlenecks)
 More accurate transport planning
 Route analysis allowing more
accurate incident management
 Environmental /
health
 Road safety
 Economy /
welfare
Requires definition
of “stage” and
handling of issues
such as engine
stalling or stopping
at petrol station or
rest area (not truly
stage start/end)
 CRM applications providing
customized user information
Time elapsed
from start to end
of travel stage;
travel time for
specific road
segments
Requires forcing of
transmission of
time-position data
in certain sections
in order to calculate
time spent within
them
Allows implementation of:
 Road safety
 Accurate measurement of travel
time as a service level
measurement
 Economy /
welfare
Number of
vehicles in a
given road
section at a
given time,
divided by
section length
Requires knowledge
of position of ALL
vehicles
Allows implementation of:
Number of
vehicles
observed in
specific road
section during
fixed time
interval
Requires knowledge
of position of ALL
vehicles
 Accessibility
 Driving behaviour control for
professional drivers
 Traffic flow theory
 Congestion detection
 Homogenous speed
 More accurate transportation
planning
Allows implementation of:
 Traffic flow theory
 More accurate transportation
planning
 Real-time traffic information
GNSS for INnovative road Applications
 Environmental /
health
 Road safety
 Economy /
welfare
 Accessibility
 Environmental /
health
 Road safety
 Economy /
welfare
 Accessibility
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
107 of 151
Information
Description
Characteristics
Measures
Policy Areas
Vehicle
direction
Instantaneous
direction of
vehicle
OBU continuously
calculates
coordinates
variation to
calculate direction
vector and matches
this against
infrastructure
information
Allows implementation of:
 Road safety
Inappropriate for
a global system
application (too
heavy a dataprocessing load)
Allows implementation of:
Detailed
vehicle
trajectory
GINA
Detailed
collection of all
position data
to completely
define vehicle
trajectory in
space-time
 Warnings to driver
 Warnings to police patrols if no
correction
 Traffic management by means of
signalling and road closures to
avoid crash risk
 Road safety
 Accident reconstruction as a
service for insurance companies
and lawsuit support
Individually,
recording of all
position data
over a specified
rolling time
period
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
108 of 151
Planning Information Requirements
The main planning information needed by government or transport authorities is approached from two
different directions: operational management and transport planning. From the point of view of
operational management we refer to those operational tasks that are commonly driven by transport
authorities (or maybe delegated on a private partner). From the transport planning point of view we
focus on the aggregate information needed in order to correctly characterise the transportation supply
and demand.
Operational management
For transport authorities the main operational tasks are related to road safety, emergency
management, infrastructure usage and user information. The information that a GNSS based system
could provide is listed below:
Operational Area
Information provided by GNSS system
Road safety






Number of incidents occurred
Incidents location (black spot)
Driver category involved
Vehicle type involved
Existing traffic conditions
Infrastructure conditions (linked with maintenance database)
Emergency
Management




Incident detection
Response time
Emergency patrol management (equipped with OBU)
Traffic response to rerouting by traffic signalling
Infrastructure
Maintenance
 Infrastructure usage and vehicle type distribution in order to define
maintenance operations
 Maintenance patrol management (equipped with OBU)
User Information
 User reaction to measures implemented (for instance VSL, toll rates or any
kind of signalling) in order to achieve a better measures implementation
Planning
For transport authorities the transport planning can be broken down into a number of phases. The
table below shows these phases and the information (if any) that a GNSS-based system can provide in
that phase.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
109 of 151
Phase
Phase Name
Description
GNSS contribution
0
Problem identification
Define needs and
stakeholders involved
Only adds supporting data to
information held by owner
1
Functional diagnosis
Characterise transport
supply and demand
 Aggregate
origin/destination
information, including vehicle type
and user characterization
 Trip repetition frequency and time
variability in order to characterize
demand in temporal terms
 Route
choices
in
order
to
characterize demand in spatial terms
 Intensity in order to characterize
infrastructure usage
2
Strategic planning
Define general objectives
in order to address
problem
No contribution
3
Actions proposal
Define actions proposed
No contribution
4
Evaluation
Evaluate how well
actions proposed
achieved defined
objectives
Multiple assessment metrics based on
variables previously defined in this
section
5.4.6.4. Summary
This class of services depends on the analysis of the journeys and position data of a large volume of
vehicles in order to establish current and historic traffic flows. Such services could be provided to
both general users, to state users and to Toll Charging entities and are conceptually similar but as
actors at the state / TC level form a specific and very important category, their needs have been
covered in some detail.
Government policies related to transport management aim to reduce transport negative externalities
so as to make transport more sustainable. The most representative policy areas are:

Reducing environmental / health effects

Improving road safety

Improving economy and social welfare

Improving accessibility and integration
These objectives can be achieved by a variety of strategies, but all share common information
requirements. Any vehicle positioning system works with two main variables, time and position. In
addition, where data are measured is as important as the definition of the variable being calculated.
This combination can then give a variety of different information. This section summarised the main
information which could be collected from a GNSS-based RUC system and how it supports policy and
resultant measures.
5.4.7. VALUE-ADDED SERVICES - AGGREGATE SERVICES - REQUIREMENTS
Typically one would expect that many such services would be provided not by the main Service
Provider of the road user charging service but by other Service Providers who receive position data
from either the main Service Provider or directly from the OBUs of road users. The intention would be
that market forces would allow the introduction of cost-effective and innovative services.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
110 of 151
Many such services are possible and it is not the intention to specify all possible services which could
be provided in a live system. Instead, the GINA project will demonstrate a range of typical services to
illustrate the technical feasibility of this type of value added service.
Req. ID
AG-1
User Type
SP, SU
Req. Category
Aggregate Services
Req. Type
Mandatory, Demonstration
Req. Title
Motorway usage
The GINA system shall provide to motorway operators information about how
traffic uses the motorway. Categorised by vehicle type, GINA shall indicate:
Req. Description

Entry and exit points to motorway

Entry and exit time

Intermediate stops, times and durations
Notes
Since the motorway network is relatively limited, this requirement can be met
without map matching as geo-fences can be defined at entry and exit points
Req. ID
AG-2
User Type
TC, SP, SU
Req. Category
Aggregate Services
Req. Type
Optional, Demonstration
Req. Title
Real-time traffic levels
Req. Description
The GINA system shall provide near real-time traffic information consisting of
traffic speeds and traffic volumes for specified roads; such information shall
be updated at intervals of 5 minutes or less and shall be displayed on an
internet site
For the purposes of the GINA project, the aim is to demonstrate that relevant
data can be gathered and appropriately analysed; its dissemination (e.g. to
OBUs) is not core to this requirement.
Notes
The roads for which such traffic information shall be provided will depend on
the roads used by the volunteer drivers, such that a sufficiently large sample
of data is available
The roads for which this requirement will be implemented in the GINA project
will need to be defined with geo-fences at their entrances / exits, as specific
geo-objects or by map-matching limited to the specific roads
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
111 of 151
Req. ID
AG-3
User Type
TC, SP, SU
Req. Category
Aggregate Services
Req. Type
Optional, Demonstration
Req. Title
Road usage analysis
Req. Description
The GINA system shall provide an analysis of the use of specific roads by
vehicle type, by day and by time of day; such information shall be displayed
on an internet site
For the purposes of the GINA project, the aim is to demonstrate that relevant
data can be gathered and appropriately analysed; its dissemination is not
core to this requirement.
Notes
The roads for which such traffic information shall be provided will depend on
the roads used by the volunteer drivers, such that a sufficiently large sample
of data is available
The roads for which this requirement will be implemented in the GINA project
will need to be defined with geo-fences at their entrances / exits, as specific
geo-objects or by map-matching limited to the specific roads
5.4.8. VALUE-ADDED SERVICES - SPECIFIC SERVICES
This class of service depends on the Service Provider knowing the location of the user. As with
aggregated services, these could be provided by multiple Service Providers.
Again, as with
aggregated services, it is not the intention to specify all possible services which could be provided.
Instead, the GINA project will demonstrate a range of typical services.
Req. ID
Req. Category
SP-1
User Type
SP, SU
Specific Services
Req. Type
Optional, Demonstration
Optional, Live
Req. Title
Real-time tracking
Req. Description
The GINA system shall allow fleet operators to track the location of their
vehicles in real-time
Notes
Real-time tracking is dependent on the OBU sending location information to
the SP continuously and, for practical purposes, it would require map
matching; for the purposes of GINA it is assumed that users will agree that
OBUs will be permitted to send positional data but, depending on the relevant
privacy legislation this may not be true in a live system. GINA is not
intending to use map-matching; unless this assumption changes, the
demonstration would be limited to providing an interface over which
positional data would be provided allowing a fleet operator to perform its own
map-matching / real-time tracking
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
112 of 151
Req. ID
SP-2
User Type
SP, SU
Req. Category
Specific Services
Req. Type
Optional, Live
Req. Title
Ecall / SOS
Req. Description
It shall be possible for the driver / passenger of a vehicle to send an
emergency signal to an operator automatically indicating the position of the
vehicle and for the call to be automatically routed to an appropriate operator
according to location
Notes
It should be possible to provide this service without map-matching – a
stationary vehicle’s location would have high integrity and it would be
relatively straightforward for the receiving operator to display this on a map
As this requirement requires a user interface to the OBU, it does not form
part of the GINA requirements
Req. ID
SP-3
User Type
SP, SU
Req. Category
Specific Services
Req. Type
Optional, Live
Req. Title
Ecall / SOS cause
Req. Description
It shall be possible for the driver / passenger of a vehicle sending an
emergency signal to indicate the type of emergency
Notes
As this requirement requires a user interface to the OBU, it does not form
part of the GINA requirements
Req. ID
SP-4
User Type
SP, SU
Req. Category
Specific Services
Req. Type
Optional, Live
Req. Title
Ecall / SOS response
Req. Description
It shall be possible for the operator receiving the emergency notification to
communicate with the driver / passenger
It is envisaged that the OBU would communicate via GSM / UMTS / GPRS –
the communication channel would be via the SIM in the OBU
Notes
As this requirement requires a user interface to the OBU, it does not form
part of the GINA requirements
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
113 of 151
Req. ID
SP-5
User Type
SP, EU
Req. Category
Specific Services
Req. Type
Optional, Demonstration
Req. Title
Driver behaviour
It shall be possible for the GINA system to analyse driver behaviour based on
received location data. Such driver behaviour shall include
Req. Description

acceleration / deceleration above configurable thresholds

speeds above configurable thresholds, including speed limits for
defined geo-objects
Notes
This covers the situation where the results, whether calculated centrally or by
the OBU, are available through an SP. See also requirement OF-31 where the
OBU performs the calculations which can then be downloaded from the OBU
Req. ID
SP-6
User Type
SP, EU
Req. Category
Specific Services
Req. Type
Optional, Demonstration
Req. Title
Emissions reporting
It shall be possible for the GINA system to report emissions information for
each vehicle, based on:
Req. Description

Vehicle emissions class

Vehicle speeds and acceleration / deceleration, including stationary
with engine idling

Engine warm-up time
The system shall report:

Total emissions per day

Average emissions per kilometre for each day

Relationships between speed / acceleration and emissions rates
Notes
5.5. BILLING REQUIREMENTS
Req. ID
B-1
User Type
SP, SU
Req. Category
Billing
Req. Type
Mandatory, Demonstration
Req. Title
Billing Frequency
Req. Description
Bills shall be produced on a monthly basis
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
114 of 151
Req. ID
B-2
User Type
SP, SU
Req. Category
Billing
Req. Type
Mandatory, Demonstration
Req. Title
Online billing
Req. Description
It shall be possible for users to view their charges online
Notes
Req. ID
B-3
User Type
SP, SU
Req. Category
Billing
Req. Type
Mandatory, Demonstration
Req. Title
Online billing timeliness
Req. Description
Charges shall be shown online within 24 hours of being incurred
Notes
Req. ID
B-4
User Type
SP, SU
Req. Category
Billing
Req. Type
Mandatory, Demonstration
Req. Title
Bill content
The monthly bill and the charging information shown online shall show the
following information:
Req. Description
Notes
GINA

Vehicle id

OBU id

Vehicle class

CO2 / emissions class
On a daily basis:

Total mileage per day

Total mileage for each tariff / time category combination

Rate for that tariff / time combination

Total charge for that tariff / time combination

Total charge for the day
In a live system which allowed for the possibility of moving an OBU between
vehicles, the day by default would be 0000-2400 but where the OBU had
been moved between vehicles, then the period covered by the OBU/vehicle
combination would need to be stated on the bill
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
115 of 151
Req. ID
B-5
User Type
SP, SU
Req. Category
Billing
Req. Type
Optional, Demonstration
Req. Title
Detailed bill analysis
It shall be possible for users to access their charges online and drill down to
the detail behind those charges in order to be able to verify the bill. The
detail required would be:
Req. Description

Time of entry / exit into / from each tariff zone

Mileage driven in that tariff zone (split by time period if the time in
zone covers more than one time period)
The time of entry / exit applies for both area / cordon type zones and for
zones where there is a per km charge within the zone.
Separate tariff zones should be differentiated in the drill-down detail even if
they carry the same tariff. Thus distances driven in / entries into, say,
Utrecht and Amsterdam should be differentiated, even if they cost the same.
Similarly, different roads / motorways should be differentiated
Notes
This would not be possible in a live system subject to restrictions similar to
the ABvM requirements
Req. ID
B-6
User Type
SP, EU
Req. Category
Billing
Req. Type
Mandatory, Demonstration
Req. Title
Security of online access
Req. Description
Access to online billing information shall be secured, by password or
otherwise, such that it shall be possible only for the account holder or
authorised SP (GINA) staff to access their details
Notes
5.6. END TO END PERFORMANCE REQUIREMENTS
Although the end-to-end performance of a road-user charging system is critically dependent on the
performance of the OBU (discussed in section 5.7.3 below) particularly in terms of the accuracy and
integrity of the individual positions calculated by the OBU, it is also dependent on how the overall
system deals with multiple positions. Other trials (e.g. TfL’s distance based charging trials) have
demonstrated that an accurate OBU does not always produce a system with the greatest overall
accuracy and that lower levels of OBU accuracy can still result in end-to-end systems with the greatest
overall accuracy.
This section deals with the end-to-end performance requirements. Principally these relate to charging
accuracy. No standards for required performance for Road User Charging systems have been
established; however, work is being carried out in this area, particularly by GMAR (GNSS Metering
Association for Road-user charging). For the purposes of this document we focus on three metrics
being developed by GMAR, analogous to the four metrics of accuracy, integrity, availability and
continuity used in navigation systems. These three metrics are:

GINA
Charging Accuracy – an Nth percentile charging accuracy is defined by GMAR as the relative
charging error magnitude that N% of charges fall within, where relative charging error is the
difference between the computed charge and the true charge due, divided by the true charge
due
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
116 of 151

Charging Integrity – whilst charging accuracy describes how accurate charges are overall, it
provides no guarantee or indication of whether the error in a particular case is below a certain
limit. Charging Integrity measures the trust that can be placed on the correctness of the
information supplied by the total system. GMAR defines Charging Integrity as the probability
(close to 1) with which the system can ensure that for a given charge the relative error is
below a specified positive limit.

Charging Availability – this combines both availability and continuity in a navigation system.
GMAR defines Charging Availability as the portion of time in which the RUC system is
delivering charges within required accuracy and integrity requirements.
Although initial definitions have been developed by GMAR, no specific parameters have been
developed for these metrics. The requirements set out below are therefore based on discussions with
ARVAL representing service users, typical error requirements for telecommunications systems along
with (non-numerical) requirements set out by the Dutch government.
Charging Availability is principally dependent on the proportion of the time that the OBU is able to
calculate positions – if it is not able to communicate with the TSP or the TSP’s systems are down,
captured data can be buffered and the charging availability is not affected. The time that the OBU can
calculate positions is principally dependent on Time to First Fix (TTFF). Since Charging Availability is
thus dependent on TTFF, which is specifically an OBU characteristic, it is not specified further in this
section; instead TTFF requirements are specified in section 5.7.3 (OBU Performance requirements).
The performance requirements for Charging Accuracy and Charging Integrity set out below are
independent of whether the OBU or the central TSP system performs calculations associating positions
with tariff zones and establishing distance traveled.
Req. ID
CP-1
User Type
Req. Category
Charging
Performance
Req. Type
Req. Title
Charging Accuracy – Percentage of bills
Req. Description
99% of monthly bills shall be 100% accurate
TC, SP, SU
Mandatory, Demonstration
Notes
Req. ID
CP-2
User Type
Req. Category
Charging
Performance
Req. Type
Req. Title
Charging Accuracy – Individual bills
Req. Description
Of bills which are inaccurate, 99.9% shall be within 0.1% of the true
monetary value
TC, SP, SU
Mandatory, Demonstration
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
117 of 151
Req. ID
CP-3
User Type
Req. Category
Charging
Performance
Req. Type
Req. Title
Charging Integrity – Overcharging
Req. Description
There shall be a 99.99% certainty that a user is not charged a higher tariff
than should have been applied.
Notes
A 100% certainty is not possible; the EGNOS / GALILEO integrity feature
states that there is an x% probability that the true position is within a certain
distance of the given position – even with a guard band there is therefore a
small probability that the position will be wrongly associated with a higher
tariff
Req. ID
CP-4
User Type
Req. Category
Charging
Performance
Req. Type
Req. Title
Charging Integrity – Journey Charge Variation
Req. Description
The charge for the same journey undertaken on different days shall not vary
by more that 0.1%
Notes
Same journey implies both the same route and the same time of day to
ensure that the same time tariffs are applied
TC, SP, SU
Optional, Demonstration
TC, SP, SU
Mandatory, Demonstration
5.7. OBU
5.7.1. OBU PHYSICAL REQUIREMENTS
The OBU to be used for the GINA project has been specified in the project proposal (Annex F). As
such, most physical requirements of the OBU are taken as a given. These include size, weight, power
consumption, Mean Time Between Failures (MTBF) etc.
Req. ID
OP-1
User Type
SP, SU
Req. Category
OBU Physical
Characteristics
Req. Type
Mandatory, Demonstration
Req. Title
Connection to CANBUS
Req. Description
It shall be possible for the OBU to connect to the CANBUS on the vehicle in
which it is installed in order to access vehicle data such as the odometer
Notes
Optional, Live
Not all vehicles have a CANBUS installed; in particular, older vehicles do not.
Different manufacturers have different CANBUS protocols, requiring an OBU
to either be customized for the specific vehicle or to be loaded with all
possible protocols. The requirement to connect to CANBUS depends on the
functional requirements of the overall system and the requirements of VAS
providers.
The GINA project will demonstrate the integration of an OBU with the
CANBUS of a vehicle (in a sub-set of the vehicles involved in the volume
trials)
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
118 of 151
Req. ID
OP-2
User Type
Req. Category
OBU Physical
Characteristics
Req. Type
Req. Title
User Interface
Req. Description
The OBU shall have an appropriate user interface
Notes
The requirement for a user interface depends on the exact user requirements
for OBU functionality, such as those for eCALL/SOS, set out in section 5.4.7
above.
SP, SU
Optional, Live
5.7.2. OBU FUNCTIONAL REQUIREMENTS
5.7.2.1. Position Determination
Req. ID
OF-1
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Position determination – EGNOS
Req. Description
The OBU shall determine its position periodically based on signals received
from the GPS system, combined with signals received from the EGNOS
system. The periodicity shall be sufficient to calculate distance travelled and
tariff zone with sufficient accuracy to meet the billing accuracy requirements
Notes
Req. ID
OF-2
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Position determination – GPS only
Req. Description
The OBU shall determine its position periodically based on signals received
from the GPS system alone. The periodicity shall be sufficient to calculate
distance travelled and tariff zone with sufficient accuracy to meet the billing
accuracy requirements.
Notes
This requirement is to allow the GINA project to compare the accuracy of
road user charging based on GPS/EGNOS and GPS alone. This will apply in
one of the configurations to be used in the exhaustive performance trials
(EGNOS information will be used in the vehicles involved in the volume trials)
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
119 of 151
Req. ID
OF-3
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
Position determination – GALILEO
Req. Description
The OBU shall determine its position periodically based on signals received
from the GALILEO system, combined if necessary with signals received from
the GPS and EGNOS systems.
Notes
This is a future requirement applicable when GALILEO becomes available
Req. ID
OF-4
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Position integrity – EGNOS
Req. Description
The OBU shall calculate the integrity of the position calculated from the
received GPS/EGNOS signals
Notes
Req. ID
OF-5
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
Position integrity – GALILEO
Req. Description
The OBU shall calculate the integrity of the position calculated from the
received GALILEO signals
Notes
This is a future requirement applicable when GALILEO becomes available
5.7.2.2. Security
It is vital that the information received by the SP from the OBU is trusted. If the OBU can be
interfered with in any way, then the positioning or charging information received from the OBU could
potentially be incorrect with the user being undercharged and a consequent loss of revenue (it is
unlikely that a user would interfere with the OBU to produce an overcharge). A system known to be
vulnerable could potentially cease to be trusted by the public. Incorrect information sent by the OBU
could also result in a distortion of traffic information, although it is unlikely that the incidence of
interference would be sufficiently high to have a statistical impact.
Two main methods of interference can be envisaged. The first is by faking or “spoofing” the received
GNSS signals. GPS signal simulators are now readily available and could easily be connected to the
OBU to fake position data. Whether this would be economically worthwhile is perhaps open to
question, taking into account the costs of the simulators (although these are now in the range of 00s
of Euros), the complexity of spoofing and the likely savings. However, should road user charging
become widespread it is likely that cheap and simple spoofing solutions would become readily
available. Neither GPS nor EGNOS provide any authentication facilities, so it is impossible for the
receiver to know whether it is receiving a real or fake signal. GALILEO will include authentication
facilities, although the details of these have not been established.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
120 of 151
The second method of interference is direct interference with the OBU itself, by altering its software,
its identity etc. One particular issue to note is that it is possible to fake the position reported by the
OBU either by spoofing the signal, as discussed above, or by compromising the calculations which use
real signals or by simply reporting fake positions programmed into the OBU. The TSP therefore needs
to know not only that the OBU is not being spoofed but also that the OBU itself can be trusted and has
not been compromised.
Req. ID
Req. Category
OF-6
User Type
SP
OBU Functionality
Req. Type
Mandatory, Demonstration
Mandatory, Live
Req. Title
Authentication
Req. Description
The OBU shall contain appropriate security hardware / software to allow
communications from the OBU to be authenticated (i.e. that the OBU is the
one that it says it is and that its calculations are secure)
Notes
This requirement is equivalent to the Trusted Entity requirement of the Dutch
ABvM system
Req. ID
OF-7
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
GNSS signal authentication
Req. Description
The OBU shall be capable of authenticating the GNSS signal received by it
Notes
This requirement will only be applicable when GALILEO is operational.
Neither GPS nor EGNOS currently provide any authentication facilities
Req. ID
OF-8
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
Reporting of GNSS signal spoofing
Req. Description
Should the OBU detect that the GNSS signal(s) that it is receiving is/are being
spoofed, it shall immediately report this to the SP
Notes
Req. ID
OF-9
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
Tamper resistance
Req. Description
The OBU shall be proof against unauthorized access to it whether physically,
electronically or by means of software
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
121 of 151
Req. ID
OF-10
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
Tamper detection and reporting
Req. Description
The OBU detect any attempts at tampering and report them to the SP
Notes
Req. ID
Req. Category
OF-11
User Type
SP
OBU Functionality
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Vehicle identification and reporting
Req. Description
Where the OBU is connected to the CANBUS, it shall detect the vehicle id and
report it to the SP
Notes
5.7.2.3. Interface to SP
Req. ID
OF-12
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Wireless interface with central system
Req. Description
The OBU shall incorporate a wireless interface for communicating with the
central TSP system and other systems operated by other Service Providers.
Notes
For the demonstration this interface shall be a GSM / UMTS / GPRS interface
Req. ID
OF-13
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Software upgrades
Req. Description
The OBU shall be capable of receiving software upgrades over the wireless
interface
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
122 of 151
Req. ID
OF-14
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Tariff zone and time data updates
Req. Description
The OBU shall be capable of receiving over the wireless interface from the
central system updates of details of geo-objects defining tariff zones and the
details of times of applicability of tariffs
Notes
Req. ID
Req. Category
OF-15
User Type
SP
OBU Functionality
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Real-time positional data and tariff zone data transmission
Req. Description
The OBU shall be capable of sending positional data and data described in
requirements OF-18 to OF-23 to the SP in real-time
Notes
In order for some user requirements to be met (e.g. real-time tracking of
vehicles), the OBU must be capable of sending positional data in real time.
Clearly if privacy constraints in a live system prohibit such user requirements,
then this requirement will be irrelevant unless system design requires these
data to be sent in real-time rather than batch mode. The GINA project shall
nevertheless demonstrate that real-time transmission is possible
Req. ID
OF-16
User Type
SP
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Category
Optional, Live
Req. Title
Batch positional and tariff zone data
Req. Description
The OBU shall be capable of sending positional data and data described in
requirements OF-18 to OF-23 to the SP in batches, the size and frequency of
the batches being defined according to operational requirements.
An
operational system may require these data to be sent in real-time (or as soon
as they are calculated) but the GINA project will demonstrate that batch
mode is possible
Notes
Req. ID
Req. Category
OF-17
User Type
SP
OBU Functionality
Req. Type
Mandatory, Demonstration
Optional, Live
Req. Title
Data storage in case of network non-availability
Req. Description
In the event of the communications network between the OBU and the SP
being unavailable, the OBU shall be capable of storing positional data and
data described in requirements OF-18 to OF-23 until the network becomes
available. The amount of data that the OBU shall be capable of storing shall
be equivalent to 24 hours of continuous driving
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
123 of 151
5.7.2.4. Tolling
Req. ID
OF-18
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Tariff zone and time data
Req. Description
The OBU shall be capable of storing details of geo-objects defining tariff
zones, details of times of applicability of tariffs and the ranking of tariff zones
(i.e. which zone has a higher tariff than another)
Notes
The ranking of tariff zones is required so that the OBU ensures that in cases
of doubt the lower tariff is charged; this is likely to be sufficient for the ABvM
requirement but for more complex systems the actual tariffs themselves may
be required
Req. ID
OF-19
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Tariff zone / time / distance calculation – EGNOS
Req. Description
Based on the positions and integrity calculated from GPS and EGNOS signals,
the OBU shall associate the positions with the appropriate geo-objects
defining tariff zones, calculate distances travelled within zone / time
combinations and any liability for single charges associated with zone /
cordon schemes
Notes
Req. ID
OF-20
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Tariff zone / time / distance calculation – EGNOS and odometer
Req. Description
Based on the positions and integrity calculated from GPS and EGNOS signals,
along with readings from the odometer via CANBUS, the OBU shall associate
the positions with the appropriate geo-objects defining tariff zones, calculate
distances travelled within zone / time combinations and any liability for single
charges associated with zone / cordon schemes
Notes
The purpose of this requirement is to allow comparisons between the
accuracy of GPS alone, GPS/EGNOS and GPS/EGNOS/odometer and will be
implemented in the test reference car used in the exhaustive performance
trial
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
124 of 151
Req. ID
OF-21
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Tariff zone / time / distance calculation – GPS alone
Req. Description
Based on the positions calculated from GPS signals alone, the OBU shall
associate the positions with the appropriate geo-objects defining tariff zones,
calculate distances travelled within zone / time combinations and any liability
for single charges associated with zone / cordon schemes
Notes
The purpose of this requirement is to allow comparisons between the
accuracy of GPS alone, GPS/EGNOS and GPS/EGNOS/odometer and will be
implemented in the test reference car used in the exhaustive performance
trial
Req. ID
OF-22
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Live
Req. Title
Tariff zone / time / distance calculation – GALILEO
Req. Description
Based on the positions and integrity calculated from GALILEO signals, the
OBU shall associate the positions with the appropriate geo-objects defining
tariff zones, calculate distances travelled within zone / time combinations and
any liability for single charges associated with zone / cordon schemes
Notes
This is a future requirement applicable when GALILEO becomes available
Req. ID
OF-23
User Type
SP
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Category
Optional, Live
Req. Title
Zone Entry / Exit
Req. Description
Based on the calculations necessary for requirements OF-18 to OF-22, the
OBU shall calculate when each tariff zone / time combination was entered and
exited. Different zones which have the same tariff shall be distinguished.
Notes
The objective of this requirement is to permit requirement B-5 (detailed bill
analysis / checking) to be met in an environment where the OBU is not
permitted to pass detailed positional data to the TSP’s central system. In
such a case it may be that details just of when each zone was entered are
considered sufficiently broad not to breach privacy requirements. The GINA
project will demonstrate that this is technically feasible, but it’s applicability in
a live system will of course depend on the specific requirements of the
relevant jurisdiction
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
125 of 151
5.7.2.5. Compliance
Req. ID
OF-24
User Type
TC, SP
Req. Category
OBU Functionality
Req. Type
Optional, Live
Req. Title
DSRC Communications with compliance unit
Req. Description
The OBU shall have DSRC equipment integrated into it to allow it to
communicate with roadside compliance units.
Notes
See section 5.10 for further details on compliance. Whether DSRC is required
in an operational system depends on the compliance methodology adopted.
This requirement will not form part of the GINA project
Req. ID
OF-25
User Type
TC, SP
Req. Category
OBU Functionality
Req. Type
Optional, Live
Req. Title
Compliance data sent to compliance unit
On being interrogated by a compliance unit, the OBU shall send by DSRC the
following information:
Req. Description
Notes

The OBU id

The vehicle id with which the OBU should be associated

Status information on the OBU, in particular whether the unit has
been tampered with
See section 5.10 for further details on compliance. Whether DSRC is required
in an operational system depends on the compliance methodology adopted.
This requirement will not form part of the GINA project.
5.7.2.6. Services
Req. ID
OF-26
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Optional, Live
Req. Title
Current location
Req. Description
The OBU shall, on demand, display the current location on a display screen
Notes
This requirement will not form part of the GINA project as no user interface is
planned for the OBU
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
126 of 151
Req. ID
OF-27
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Optional, Live
Req. Title
Current location
Req. Description
The OBU shall, on demand, provide the current location to other devices
through an electronic interface
Notes
This requirement will not form part of the GINA project as no user interface is
planned for the OBU
Req. ID
OF-28
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Optional, Live
Req. Title
Broadcast information filtering
Req. Description
The OBU shall be capable of receiving broadcast information and by filtering
according to location and travel direction displaying to the user only that
information which is relevant. The method of broadcast is not defined
Notes
This requirement will not form part of the GINA project as no user interface is
planned for the OBU
Req. ID
OF-29
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Positional Data Storage and download
Req. Description
The OBU shall store its calculated position and integrity at configurable
intervals, which may be more infrequent than the frequency at which
positions are calculated. These positions shall be capable of download via a
direct electronic interface
Notes
Req. ID
OF-30
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Positional Data Storage capacity
Req. Description
The OBU shall be capable of storing 20,000 positions
This requirement is related to requirement OF-29, rather
requirements for buffering data prior to batch upload to the TC.
Notes
GINA
than
to
The number of positions is based on a position being recorded every 5
minutes over an 8 hour driving day, 5 days a week, with a download every 6
months, with a substantial margin for error
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
127 of 151
Req. ID
OF-31
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Driver behaviour calculation, storage and download
Req. Description
Based on positions and integrity calculated from received GPS and EGNOS
signals as well as data received from CANBUS (where available), the OBU
shall calculate and store the acceleration, deceleration and speed of the
vehicle. These indicators of driver behaviour shall be capable of download via
a direct electronic interface. The data storage capacity related to this
requirement remains to be determined
Notes
In principle, speed and acceleration/deceleration can be calculated directly
from GNSS positional data, without recourse to odometers or accelerometers
via CANBUS, provided that the GNSS positional data are reported sufficiently
frequently
Req. ID
OF-32
User Type
SP, SU
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Pre-accident information
Req. Description
The OBU shall maintain a rolling buffer of 10 minutes worth of detailed
positional and behavioural information. Recording of this information shall be
halted and the buffer preserved when the OBU detects that the vehicle has
been involved in an accident. This information shall be capable of download
via a direct electronic interface
Notes
Detection of involvement in an accident could be done by means of an
accelerometer, connection to which is not envisaged in GINA. Alternatively,
GNSS positional data can be processed to calculate speed and acceleration
and hence give rise to detection of an abnormal / catastrophic deceleration
5.7.3. OBU PERFORMANCE REQUIREMENTS
As discussed in section 5.6 above, there are three key end-to-end charging performance
requirements:

Charging Accuracy

Charging Integrity

Charging Availability
Two of the key factors involved in Charging Accuracy and Charging Integrity are the accuracy and
integrity of the OBU in calculating an individual position; however, these are not the only factors. The
processing of these individual positions is also critical; for example, there are software techniques
which take into account the previous positions in re-calculating the next position or in rejecting it.
Similarly, it is possible that reported positions will be scattered either side of the actual line of travel;
even if these are a matter of a metre or so off, “joining the dots” to calculate the distance travelled
will result in an overstatement of distance travelled. Techniques of calculating lines of best fit will
therefore need to be applied. Thus it is inappropriate to specify exact performance requirements for
accuracy and integrity for the OBU alone – what is relevant is overall end-to-end performance.
By contrast, Charging Availability is principally dependent on the Time to First Fix (TTFF) of the OBU
and a performance requirement for this is therefore stated.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
128 of 151
Req. ID
OP-1
User Type
SP
Req. Category
OBU Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Time to First Fix
Req. Description
The OBU shall have a time to first fix of less than 30 seconds from the time of
entering into signal coverage
Notes
When an OBU is switched on or enters into satellite coverage from an area of
no coverage (e.g. an underground garage) there is a lag before a first
position can be calculated. This is known as the “Time to First Fix (TTFF)”.
Clearly, whilst the OBU is trying to get a fix, it cannot be reporting any
positions and any distance driven during this time cannot be charged. TTFF is
the critical element in the charging availability performance which was
discussed in section 5.6.
A TTFF of 30 seconds would, in an urban area with a speed limit of 50kph,
result in a maximum uncharged distance of approx. 400m
5.8. OBU SUPPORT SERVICE
A live system would require that a major operation be put in place for the management of OBUs,
including their supply, return, transfer between vehicles and replacement. The specification of
requirements for such a system is outside the scope of the GINA project, where only a small number
of OBUs (100) are to be supplied.
5.9. CUSTOMER RELATIONSHIP MANAGEMENT (CRM) SYSTEM
5.9.1. INTRODUCTION
Any system involving customers / users requires some form of CRM system and an RUC system will be
no different. CRM systems are widespread and their attributes in terms of information held (name,
address, bank details etc.) and how this is added, altered (e.g. in case of change of address) and
deleted are well understood. It is, therefore, not proposed to describe these sort of general
requirements in this document. Instead this section focuses on the characteristics specific to a RUC
system, in particular the relationships between OBUs, vehicles and customer accounts.
There will need to be some relationship between vehicle id (i.e. the Vehicle Registration Mark or VRM)
and the OBU id, for a variety of reasons. Above all the correct vehicle / account needs to be charged.
In addition, tariffs might vary between classes of vehicle / emissions category, so it is obviously
undesirable that it should be possible to move an OBU which is for a low tariff class to a vehicle of a
high tariff class without detection. Thus the vehicle which the OBU is or ought to be in needs to be
identified. This could be done by a variety of methods – an integrating the OBU so that it physically
cannot be moved, by connecting to CANBUS, by a Bluetooth connection to the integrated electronics
etc. The association between vehicle and OBU needs to be stored in the CRM.
A related issue is that there might be legitimate reasons to move an OBU between vehicles or for the
tolls for an OBU / vehicle to be charged temporarily to a different account. Examples include
borrowing a friend’s car, when getting a courtesy car when a car is being serviced / repaired etc. This
could be addressed by Smart cards, physically moving the OBU or temporarily associating an OBU
with a different account.
The OBU to be used for the GINA project does not provide for a Smart card and it is not readily
movable between vehicles. Consequently, the issues addressed in this section will be dealt with in the
GINA project by relevant associations in the CRM.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
129 of 151
5.9.2. CRM FUNCTIONALITY
Req. ID
CR-1
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Online access
Req. Description
It shall be possible for service users to access their records online and view
and update their records
Notes
Req. ID
CR-2
User Type
SP, EU
Req. Category
Billing
Req. Type
Mandatory, Demonstration
Req. Title
Security of online access
Req. Description
Access to customer information shall be secured, by password or otherwise,
such that it shall be possible only for the account holder or authorised SP
(GINA) staff to access their details
Notes
Req. ID
CR-3
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
OBU id
Req. Description
The CRM system shall hold id details of all registered OBUs
Notes
Req. ID
CR-4
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Vehicle details
The CRM system shall hold details of all vehicles registered for the RUC
scheme. Details shall include:
Req. Description
Notes
GINA

Vehicle Registration Mark (VRM)

Make

Model

Colour

Vehicle Class

Emissions Class
Make, model and colour are required, in addition to VRM, for enforcement
purposes to distinguish authorized and cloned vehicles. In practice, these
data may be held in the national vehicle registry and accessed as and when
required for enforcement. Vehicle class and emissions class are required in
order to establish the appropriate level of charge to be applied
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
130 of 151
Req. ID
CR-5
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Account details
Req. Description
The CRM system shall hold details of all account holders responsible for
paying RUC charges
Notes
For the GINA demonstration, no real bills will be issued, nor actual charges
collected. Nevertheless, the issuing of a nominal bill requires a nominal
account holder; account details will be minimal and fictitious (e.g. “ABC
Company”) or simply the VRM of the vehicle
Req. ID
CR-6
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Default account for vehicle
Req. Description
Each vehicle shall be associated with one, and only one, default account
Notes
Req. ID
CR-7
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Temporary account for vehicle
Req. Description
It shall be possible to temporarily associate a vehicle with a different account,
with the permission of the owner of the different account. Whilst this
temporary association is in place, charges for the vehicle shall be applied to
the temporarily associated account and not the default account
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
Req. ID
CR-8
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Multiple vehicles on account
Req. Description
An account may have multiple vehicles associated with it at any one time, as
default or temporarily
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
131 of 151
Req. ID
CR-9
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Zero vehicles on account
Req. Description
An account may have zero vehicles associated with it at any one time
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
Req. ID
CR-10
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Nominal OBU Vehicle Association
Req. Description
Each vehicle shall have one and only one OBU associated with it at any one
time; each OBU shall be associated with one and only one vehicle at any one
time. This association represents the vehicle in which each OBU is expected
to be located
A live system would require a facility for deregistration of vehicles taken off
the road temporarily or out of the country permanently and appropriate
handling of the vehicle / OBU linkage in these circumstances.
These
considerations are not part of the GINA demonstration
Notes
This requirement is for a strict one-to-one vehicle / OBU relationship; in a live
system, OBUs could be associated with no vehicle if they are on the system
but have not been distributed to vehicles or have been returned, in which
case the requirement would be for an OBU to be associated with at most one
vehicle at any one time. These logistical aspects of OBU handling and
distribution do not form part of the GINA demonstration
Req. ID
CR-11
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Actual OBU Vehicle Association
Req. Description
If the OBU informs the CRM of the identity of the vehicle in which it is located
(obtained through a connection to CANBUS, not necessarily present in all
cases) this actual association shall be recorded alongside the nominal
association
Notes
If the actual and nominal associations are different, this would be an
indication of possible fraudulent behaviour. In a live system, not all vehicles
would have a CANBUS and therefore this reporting would not be possible in
all cases. For the GINA demonstration only a limited number of vehicles will
have a CANBUS interface.
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
132 of 151
Req. ID
CR-12
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Non-liability for charges – vehicle
Req. Description
It shall be possible to flag a vehicle as not being liable for charges due to the
type of vehicle (e.g. zero emissions vehicles or buses might not be liable)
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
Req. ID
CR-13
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Non-liability for charges – account holder
Req. Description
It shall be possible to flag a vehicle as not being liable for charges due to the
account holder (e.g. police vehicles or diplomats’ vehicles might not be liable)
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
Req. ID
CR-14
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Non-liability for charges – personal
Req. Description
It shall be possible to flag a vehicle as temporarily not being liable for charges
due to the person using it (e.g. a holder of a disability Blue Badge might not
be liable for charges in any vehicle which he/she is driving or being driven in)
Notes
This requirement may form part of a live RUC system; however, it is not
GNSS specific and is therefore optional for the GINA demonstration
Req. ID
CR-15
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Personal exemption holders
Req. Description
Individuals with a personal exemption, as per requirement CR-14, shall be
registered on the CRM system
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
133 of 151
Req. ID
CR-16
User Type
SP, SU
Req. Category
CRM Functionality
Req. Type
Mandatory, Demonstration
Req. Title
Single personal exemption
Req. Description
Only one vehicle can be registered for exemption from charges for an exempt
individual at any one time
Notes
This requirement will form part of a live RUC system; however, it is not GNSS
specific and is therefore optional for the GINA demonstration
5.10. COMPLIANCE / ENFORCEMENT
5.10.1. OVERVIEW
Compliance can be defined as ensuring that a driver complies with the key legal requirements of a
GNSS based road user charging system, namely that:

a vehicle which is liable to road user charging has an OBU installed

the OBU installed matches that vehicle or that class of vehicle, as appropriate to the charging
scheme

the OBU is switched on and functioning whilst the vehicle is being driven on chargeable roads,
including having a smartcard inserted if appropriate to the charging scheme

the OBU id and data transfer from the OBU have not been interfered with
Compliance can be ensured through positive incentives in the form of monetary inducements to carry
an OBU. It can also be ensured through an enforcement regime where a) there is a reasonable
degree of certainty that users breaching the requirements will be detected in so doing and b) that
sufficiently heavy sanctions imposed to deter users from trying to avoid payment. For the purposes of
this project, we are concerned with the compliance detection part of the system. The legal and other
measures taken once a user has been detected to be in violation of the scheme’s requirements are
beyond the scope of the project, as are any positive inducements for compliance.
It should be noted that there are two types of Toll Charging entities – infrastructure operators and
governments, who have different objectives and therefore different requirements from a compliance /
enforcement regime. A government sets tariffs primarily to attain certain policy objectives and to
raise tax revenue. Its requirement from a compliance / enforcement regime is to ensure that
sufficient people comply so that the objectives are met – 100% compliance is not necessarily
required; from a revenue point of view all tax regimes have some leakage. By contrast, an
infrastructure operator sets a tariff typically to recoup the costs of building and operating or to repay
licence costs; prior to the introduction of a GNSS system it will often have 100% compliance due to
physical barriers etc. A GNSS system which does not have 100% compliance could therefore result in
revenue loss and therefore damage to its business model. This is not true in all cases - a freeflow
system using high a high penetration of DSRC (e.g. Melbourne) has the same enforcement issues as a
GNSS based system. However, the basics of compliance detection will be the same for both types of
TC – the difference will lie in the enforcement approaches used; and it is the compliance detection
which we are principally concerned with here.
Detecting whether a vehicle is compliant or not can be done either by:

GINA
The OBU continuously transmitting information as to its state – this is inadequate as it is
impossible to detect, if nothing is being received, whether this is legitimate or whether the
OBU has been illegally disconnected.
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
134 of 151

The OBU being interrogated by roadside enforcement equipment as to its identity and its
state. This requires a communication method being integrated into the OBU, typically DSRC.

Roadside equipment automatically reading the number plate of the vehicle and, through
communication with the central system, determining whether an OBU should be on board and
the id and status of that OBU. This does not require communication between the roadside
equipment and the OBU.
The first method is disregarded. Either of the two latter methods could be used in a live system. For
the ABvM system, the Dutch government has specified that the second, using DSRC, shall be used.
For the purposes of the GINA project, only the last, using ANPR only, will be demonstrated. This
method would not in and of itself detect the manipulation of data transfer from the OBU; however the
trusted element of the OBU should detect it and notify the central system – thus when the vehicle is
detected by ANPR, enforcement can take place. Similarly if the OBU id is manipulated the trusted
element should detect it; in addition if manipulation of the OBU id has taken place, then as far as the
central system is concerned the correct OBU which should be in the vehicle is not transmitting and
this would be treated from the compliance detection point of view as if there were no OBU in the
vehicle.
5.10.2. COMPLIANCE REQUIREMENTS
The compliance requirements specified in this section are for the requirements related to the central
system and its interface with compliance units. No requirements have been specified for the
compliance units themselves as these do not form part of the core GINA project. The intent is that
the project will demonstrate that the central system can carry out the processing and communications
required for compliance, but not the operational processes of a live compliance & enforcement system.
Req. ID
CO-1
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Compliance Unit Communications with central system
Req. Description
Communication between compliance units and the central system shall be
possible by wireless technology. For the purposes of the GINA demonstration
this shall be UMTS / GPRS.
Notes
Req. ID
CO-2
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Live
Req. Title
Fixed Compliance Unit Communications with central system
Req. Description
Communication between fixed compliance units and the central system shall
be possible by fixed line communications (e.g. IP over DSL)
Notes
Fixed compliance units are not envisaged for the demonstration. In a live
system, the communication method between an individual fixed unit and the
central system would be decided on the basis of data volumes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Req. ID
Req. Category
D2.1
15/09/2009
2.0
135 of 151
CO-3
User Type
SP
Compliance
Req. Type
Optional, Demonstration
Optional, Live
Req. Title
Mobile Compliance Unit Communications with central system
Req. Description
Communication between mobile compliance units and the central system shall
be possible by fixed line communications (e.g. IP over DSL). This covers
mobile, portable and hand-held compliance units
Notes
It can be envisaged that a portable unit could be set up at the roadside and
left unmanned, recording the passage of vehicles and that the data from the
unit is then uploaded to the central system in batch form when the unit is
returned to base.
Req. ID
CO-4
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Compliance data sent from compliance unit to central system
The central system shall receive from the compliance unit the following data
for each individual read:
Req. Description

Compliance unit ID

Compliance unit GNSS Location

Time

Vehicle Registration Mark if ANPR is being used

Time ANPR read was made / OBU was interrogated

Whether a VRM/OBU status is required
Notes
For enforcement purposes, the time and place where the vehicle was detected
will be required
Req. ID
CO-5
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Individual receipt of Compliance data
Req. Description
The central system shall be capable of receiving compliance data separately
for each individual read
Notes
Req. ID
CO-6
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Batch receipt of Compliance data
Req. Description
The central system shall be capable of receiving compliance data for a
number of individual reads in batch form
Notes
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
136 of 151
Req. ID
CO-7
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Compliance data sent from central system unit to compliance unit
If requested by the compliance unit, the central system shall send to the
compliance unit the following data
Req. Description

VRM

OBU id linked to that VRM

Time [ and location ] when OBU last sent a position

Whether the central system has detected that a potential noncompliance has been detected
Notes
The time and location when the OBU which should be in the vehicle last sent
a position enables the operator of the compliance unit to decide whether the
vehicle should be stopped for a compliance check. Note that because the
OBU may not upload data in a timely fashion, the fact that the OBU
associated with the vehicle has not uploaded recently does not necessarily
indicate a compliance violation. However, if the vehicle is detected in
Amsterdam and the last upload was in Utrecht 3 days ago then a violation is
probable. The central system, having historic data available to it, is also able
to detect whether the vehicle is potentially non-compliant.
Req. ID
CO-8
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Compliance violation analysis
Req. Description
Based on data received from compliance units and data uploaded from OBUs,
the central system shall calculate whether it is possible that a vehicle is not
compliant with the system requirements
Notes
Whilst it is possible that a single instance of a VRM being detected without an
OBU having uploaded recently is just a delay in data upload, a pattern of such
detections is likely to indicate a compliance violation
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
137 of 151
Req. ID
CO-9
User Type
SP
Req. Category
Compliance
Req. Type
Mandatory, Demonstration
Req. Title
Compliance check data sent from compliance unit to central system
The central system shall receive from the compliance unit the following data
Req. Description

Compliance unit ID

Compliance unit GNSS Location

Time

Vehicle Registration Mark

Whether a compliance check was carried out

Time of compliance check

Whether an OBU was found in the vehicle

The id of the OBU

Whether the OBU was switched on or off or was malfunctioning

Whether a compliance violation had occurred
Notes
If the compliance unit operator or central system decides that a compliance
violation has taken place, the operator may stop the vehicle to check the
OBU. The results of the check need to be reported back to the central system
Req. ID
CO-10
User Type
SP
Compliance
Req. Type
Optional, Demonstration
Req. Category
Req. Title
Req. Description
Optional, Live
Request for ANPR photographs by central system
If a potential or actual compliance violation has occurred the central system
may request the compliance unit to send the photographs taken of the
vehicle on which the ANPR read was based. The central system may also
instruct the compliance unit that the photographs are not required and should
be deleted.
The central system shall receive the requested photographs either in batch
mode or individually
Notes
If a compliance violation has occurred then, depending on the laws applicable
in the country, it may be necessary that, for enforcement purposes,
photographic evidence is retained showing that the vehicle was detected at a
certain time and place. The central system would therefore need to request
those photographs (which might show just the vehicle number plate and the
whole scene including the vehicle).
5.11. TC / SP TO DRIVER COMMUNICATIONS
When a measure involving an economic cost for drivers is implemented to manage the traffic flow, it is
very important to consider users as clients and let them know the conditions of the service they are
buying. Access to information regarding the conditions of the tariff imposed over the infrastructure is
vital, since most users will base their decision on what lane or route to use or when to travel
depending on this information. This section considers how the Toll Charger of Service Provider could
communicate this information to the Service User. Although this is not part of the scope of the GINA
project, it would form a key part of the requirements for a live system and is therefore considered
here, albeit at a high level.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
138 of 151
This section first sets out the main methods of communicating tariffs to users and their pros and cons
and then sets out how these methods can be utilised for various types of information and different
tolling schemes.
Ways to provide
information
Pro
Cons
Internet (official web
page)
 Very cheap
 Flexible (mobile phone)
 Reach many people, especially
the young ones
 Continual information
 Not everybody feels comfortable
with this system, for example
some older people.
 For remote access a mobile phone
connection is needed.
Adverts in newspapers
 Reach many people, especially
adults
 Punctual information
 Requires some investment
Information to the OBU
 Uses short messages that allow
to send simple texts easy to
understand
 The information sent is updated
on real time.
 With short messages there is a
limit in the amount of information
that can be sent
 The quality of the information
used depend on the data available
Fixed road-side signs
 The invariability of the message
allows the driver to get used to
the content reducing the
attention required to inform.
 No flexibility – fixed message
content
 Not suitable to inform about a
complex tariff structure with many
variations in the fare
Variable road-side signs
 The variation in the message
content allow the delivery of
different information during
various periods of time
 The message variation requires
that the user process the
information each time.
Leaflets distribution
 Although this method allow giving
different information during the
day, it is impossible to deliver all
the details of a very complex
tariff.
SMS
 Uses short messages that allows
the sending of simple, easy to
understand information
 Periodical messages, as for the
clients of a PAYD system, with
information about the follow up
of his behaviour help to create
awareness in the driver.
 The evident danger associated
with the manipulation of a mobile
phone during driving makes this
method unsuitable to deliver
information during the trip
Email
 Periodical messages, like for the
clients of a PAYD system, with
information about the follow up
of his behaviour helps to create
awareness in the driver.
 Not everybody feel comfortable
with this system, for example
some older people.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Ways to provide
information
Pro
Cons
 Sending a record of the bills
allow the user to analyse and
control his use of the vehicle.
Bill
D2.1
15/09/2009
2.0
139 of 151
 The management required for
physical sending of bills to users
can be expensive, but this is
something that could be done
through the internet, reducing
cost.
The following schemes show the features of the communications between the service provider and the
driver with subjects such as: what information must be given (content), where it should be provided
(what means can be used in order to assure that the driver gets the information about the service
used) and when these communications are established (before, during or after the trip.)
Information features
Bill
Measure
SMS
Variable roadside signs
Fixed roadside signs
Information to
the OBU
As general information
Leaflets
General
structure of
tariff
Adverts in
newspapers
When must be provided
Internet -email
Type
Appropriate way to provide
information
All
During the route planning
Applicability to
the user
Periods of
restriction times of
applicability
Approaching a tariff zone
During the change of route
- entering a tariff zone
During the route planning
Approaching a tariff zone
During the change of route
- entering a tariff zone
During the route planning
How much the
user will be or
have been
charged
Approaching a tariff zone
During the change of route
- entering a tariff zone
When checking bills
GINA
HOV
Lane
GNSS for INnovative road Applications
Variable
Toll
Variable
Toll
HOT
Lane
HOT
Lane
Variable
Toll
FAIR
Lane
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Information features
Periods of
restriction times of
applicability
Bill
Variable roadside signs
SMS
Fixed roadside signs
All
Approaching a tariff zone
During the change of route
- entering a tariff zone
Approaching a tariff zone
During the change of route
- entering a tariff zone
At exiting a tariff zone
During the route planning
How much the
user will be or
have been
charged
Measure
During the route planning
During the route planning
Zones
regulatedapplicable to
specific zone
Information to
the OBU
As general information
Leaflets
General
structure of
tariff
Adverts in
newspapers
When must be provided
Appropriate way to provide
information
Internet-email
Type
D2.1
15/09/2009
2.0
140 of 151
Road
Space
Rationing
One
Point
Tariff
Mixed
Tariff
Approaching a tariff zone
During the change of route
- entering a tariff zone
When checking bills
at exiting a tariff zone
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
Information features
General
structure of
tariff
How much the
user will be or
have been
charged
Measure
Bill
Variable roadside signs
SMS
Fixed roadside signs
Information to
the OBU
Leaflets
Adverts in
newspapers
When must be provided
Appropriate way to provide
information
Internet -email
Type
D2.1
15/09/2009
2.0
141 of 151
As general information
Pay as
you
Drive
During the route planning
When checking bills
5.12. REQUIREMENTS SUMMARY
The tables in this section summarise the user requirements set out in the body of this chapter. A
summary description is given where the requirement title is not self-explanatory. Please refer to the
relevant sections above for a full description, including context, applicability and whether each
requirement is mandatory or optional.
5.12.1. PRIVACY
Requirement ID
Title
Summary Description
PR-1
Data Protection
No personal data to be used for purposes other than
those specified by law or agreed to by users
PR-2
Security of personal data
in GINA
Personal data to be kept secure within project and
destroyed at project end
PR-3
No detailed location data
Not possible to determine individual user’s location or
journey details
PR-4
Opt-in for location data
for general services
Users can allow location data to be used
PR-5
Opt-in for location data
for individual services
Users can allow location data to be used but only for
provision of services to them
PR-6
Limitations on data
passed from TSP to VSP
Positional data passed from TSP to VSP to be
minimum amount necessary
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
142 of 151
5.12.2. ROAD USER CHARGING
Requirement ID
Title
Summary Description
CH-1
Per kilometre charge
Possible to charge vehicles per kilometre driven
CH-2
Variation in per
kilometre charge by
location
CH-3
Variation in per
kilometre charge by
specific road
CH-4
Variation in per
kilometre charge by
specific road class
CH-5
Cordon charge
CH-6
Cordon charge variation
by direction
CH-7
Area charge
CH-8
Private property
exemption
Driving on private property exempted from road user
charging
CH-9
Time of day charging
Possible to vary charges by time of day / day of week
CH-10
Time of day charging
variation by location
Time bands can vary by location
CH-11
Vehicles / emissions
class charging
Variation of charges by vehicle / emissions class
CH-12
Vehicle and vehicle class
exemption
Specific vehicles or classes exempt from charge
CH-13
Individual exemption
Specific individuals exempt from charge
CH-14
Charge type combination
Any combination of CH-1 to CH-13 possible
CH-15
Dynamic charging
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
143 of 151
5.12.3. VALUE-ADDED SERVICES - PAY AS YOU DRIVE
Requirement ID
Title
Summary Description
PY-1
Per kilometre charge
PY-2
Variation in per
kilometre charge by
location
PY-3
Variation in per
kilometre charge by
specific road
PY-4
Variation in per
kilometre charge by
specific road class
PY-5
Private property
exemption
Driving on private property exempted from charging
PY-6
Time of day charging
Possible to vary charges by time of day / day of week
PY-7
Time of day charging
variation by location
Time bands can vary by location
PY-8
Vehicle charging
Possible for charges to vary by specific vehicle
PY-9
Individual charging
Possible for charges to vary by individual
PY-10
Driving style charging
Possible for charges to vary according to driving style
PY-11
Charge type combination
Any combination of PY-1 to PY-10 possible
5.12.4. VALUE-ADDED SERVICES - AGGREGATE SERVICES
Requirement ID
Title
Summary Description
AG-1
Motorway usage
Provision of information motorway use by vehicle
type (entry and exit points and times and
intermediate data)
AG-2
Real-time traffic levels
Provision of near real-time traffic information (traffic
speeds / volumes) for specified roads
AG-3
Road usage analysis
Provision of analysis of the use of specific roads by
vehicle type, by day and by time of day
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
144 of 151
5.12.5. VALUE-ADDED SERVICES - SPECIFIC SERVICES
Requirement ID
Title
Summary Description
SP-1
Real-time tracking
Real-time vehicle tracking for fleet operators
SP-2
eCall/ SOS
Emergency signal to operator showing location
SP-3
eCall / SOS cause
Cause of emergency as automatic part of signal
SP-4
eCall / SOS response
Possible for operator to communicate with driver
SP-5
Driver behaviour analysis
SP-6
Emissions reporting
5.12.6. BILLING
Requirement ID
Title
Summary Description
B-1
Billing Frequency
Monthly bills
B-2
Online billing
B-3
Online billing timeliness
Charges shown online within 24 hrs of being incurred
B-4
Bill content
Specifies what shall be shown on bill
B-5
Detailed bill analysis
Possible for users to analyse bills in detail; specifies
level of detail
B-6
Security of online access
Billing information accessible only to account holder
5.12.7. CHARGING PERFORMANCE
Requirement ID
Title
Summary Description
CP-1
Charging Accuracy –
Percentage of bills
99% of bills 100% accurate
CP-2
Charging Accuracy –
Individual bills
99.9% of inaccurate bills within 0.1% of true
monetary value
CP-3
Charging Integrity –
Overcharging
99.99% certainty that tariff higher than true tariff is
not charged
CP-4
Charging Integrity –
Journey Charge Variation
Variation of charge for same journey on different
days < 0.1%
5.12.8. OBU PHYSICAL REQUIREMENTS
Requirement ID
Title
OP-1
Connection to CANBUS
OP-2
User Interface
GINA
Summary Description
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
145 of 151
5.12.9. OBU FUNCTIONAL REQUIREMENTS
Position Calculation
Requirement ID
Title
Summary Description
OF-1
Position determination –
EGNOS
EGNOS to be used for position determination
OF-2
Position determination –
GPS only
OF-3
Position determination –
GALILEO
GALILEO to be used for position determination when
available
OF-4
Position integrity –
EGNOS
Position integrity to be calculated from EGNOS
OF-5
Position integrity –
GALILEO
Position integrity to be calculated from GALILEO when
available
Requirement ID
Title
Summary Description
OF-6
Authentication
Authentication of communications from OBU
OF-7
GNSS signal
authentication
OBU to authenticate received GNSS signal
OF-8
Reporting of GNSS signal
spoofing
OBU to report spoofing
OF-9
Tamper resistance
OF-10
Tamper detection and
reporting
OBU to detect and report attempted tampering
OF-11
Vehicle identification and
reporting
Where OBU is connected to CANBUS, vehicle id to be
reported
Requirement ID
Title
Summary Description
OF-12
Wireless interface with
central system
OF-13
Software upgrades
OBU to receive upgrades over wireless interface
OF-14
Tariff zone and time data
updates
OBU to receive tariff updates over wireless interface
OF-15
Real-time positional data
and tariff zone data
transmission
OBU capable of sending positional data to SP in realtime
OF-16
Batch positional and
tariff zone data
OBU capable of sending positional data to SP as batch
data
OF-17
Data storage in case of
network non-availability
OBU to store 24 hours of driving data if network
unavailable
Security
Interface to SP
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
146 of 151
Tolling
Requirement ID
Title
Summary Description
OF-18
Tariff zone and time data
OBU to store tariff zone and time data
OF-19
Tariff zone / time /
distance calculation –
EGNOS
OBU to calculate distances in zones using GPS and
EGNOS
OF-20
Tariff zone / time /
distance calculation –
EGNOS and odometer
OBU to calculate distances in zones using GPS,
EGNOS and odometer
OF-21
Tariff zone / time /
distance calculation –
GPS only
OBU to calculate distances in zones using GPS only
OF-22
Tariff zone / time /
distance calculation –
GALILEO
OBU to calculate distances in zones using GALILEO
when available
OF-23
Zone Entry / Exit
OBU to calculate when tariff zones entered / exited
Requirement ID
Title
Summary Description
OF-24
DSRC Communications
with compliance unit
OBU to incorporate DSRC
OF-25
Compliance data sent to
compliance unit
Specifies data to be sent to compliance unit when
interrogated
Requirement ID
Title
Summary Description
OF-26
Current location
OBU to display current location
OF-27
Current location through
electronic interface
OBU to provide current location to other devices
OF-28
Broadcast information
filtering
OBU to filter and display broadcast information
according to location
OF-29
Positional Data Storage
and download
OBU to store positional data for subsequent download
through direct interface
OF-30
Positional Data Storage
capacity
Specifies minimum data storage capacity
OF-31
Driver behaviour
calculation, storage and
download
OF-32
Pre-accident information
Compliance
Services
GINA
Rolling buffer of 10 mins of detailed positional data to
be preserved in case of accident
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
147 of 151
5.12.10. OBU PERFORMANCE REQUIREMENTS
Requirement ID
Title
Summary Description
OP-1
Time to First Fix
TTFF to be less than 30 seconds
5.12.11. CRM FUNCTIONALITY
Requirement ID
Title
Summary Description
CR-1
Online access
Users to access / update data online
CR-2
Security of online access
Account data accessible only to account holder
CR-3
OBU id
CRM system to hold details of all registered OBUs
CR-4
Vehicle details
Specifies details of vehicles registered for scheme to
be held by CRM system
CR-5
Account details
CRM system to hold details of account holders
CR-6
Default account for
vehicle
Each vehicle associated with one, and only one,
default account
CR-7
Temporary account for
vehicle
Possible to temporarily associate vehicle with
different account
CR-8
Multiple vehicles on
account
CR-9
Zero vehicles on account
Account may have zero vehicles associated with it
CR-10
Nominal OBU Vehicle
Association
One-to-one OBU / vehicle association
CR-11
Actual OBU Vehicle
Association
CRM system notes if OBU is identified as being in
different vehicle
CR-12
Non-liability for charges
– vehicle
CRM system notes if vehicle not liable for charges
CR-13
Non-liability for charges
– account holder
CRM system notes if account holder not liable for
charges
CR-14
Non-liability for charges
– personal
CRM system notes if vehicle not liable for charges due
to person temporarily using it
CR-15
Personal exemption
holders
Holders of personal exemptions registered on CRM
system
5.12.12. COMPLIANCE
Requirement ID
Title
Summary Description
CO-1
Compliance Unit
Communications with
central system
Wireless communications for all
CO-2
Fixed Compliance Unit
Communications with
central system
For fixed compliance units, fixed-line communications
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
148 of 151
Requirement ID
Title
Summary Description
CO-3
Mobile Compliance Unit
Communications with
central system
For mobile compliance units, option of fixed-line
communications
CO-4
Compliance data sent
from compliance unit to
central system
Specifies data to be sent by compliance unit
CO-5
Individual receipt of
Compliance data
Central system capable of receiving compliance data
separately for each individual read
CO-6
Batch receipt of
Compliance data
Central system capable of receiving compliance data
in batch form
CO-7
Compliance data sent
from central system unit
to compliance unit
Specifies data sent to compliance unit on request
CO-8
Compliance violation
analysis
Central system to calculate if vehicle may be noncompliant
CO-9
Compliance check data
sent from compliance
unit to central system
Specifies data received from compliance unit after
compliance check
CO-10
Request for ANPR
photographs by central
system
Central system to receive ANPR photographs from
compliance unit on request
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
149 of 151
6. CONCLUSIONS
As a general overview of current situation it is noticeable that current systems have several limitations
that GNSS may help to overcome. These limitations are mostly related to road type support and
vehicle type support.
The economic factor is also very relevant in currently implemented systems. They depend too much
on costly road side infrastructures that also have a considerable cost associated with their
maintenance and operation.
GNSS main costs are related to OBUs and communications. These must be taken into account and
compared against today’s typical costs (like road side infrastructures installation and maintenance).
Although the cost-effectiveness of GNSS may vary when compared with other solutions, the flexibility
that GNSS brings opens the doors to new business opportunities. This potentially brings new services
to drivers and more revenue to system operators (like car leasing companies, concessionaires or
governments).
If communication costs are not addressed correctly from the beginning, it will be the driver to pay
these extra costs, increasing the price per kilometre. On the other hand the telecommunication
providers might face in the beginning a problem related to overload of their systems. Although this
might sound like a problem, the fresh revenues will help them address this problem by upgrading their
networks and eventually allowing them to offer new services as value added services to drivers and
other service providers. Depending on the used pricing scheme and the existence of real time
services, communication may or may not be a real problem. If neither the price scheme nor the value
added services require real time data transmission, then no significant problem should be expected.
Road user charging is a delicate political matter. When introducing new schemes of road taxing and
transportation in general there are always fears of taxes increasing and concerns about the reliability
of the new scheme. In this way, before introducing GNSS to the road sector, many studies were made
to provide evidence on the reliability of the technology, specifically its precision and accuracy.
Examples of these projects are GIROADS, ARMAS and VeRT, that contributed to the credibility of the
technology. If by any chance the credibility of the technology becomes questionable by the end users,
its adoption will fail.
GNSS systems are starting to appear across Europe and in the long term their flexibility and credibility
will prove to be major advantages against other technologies. In the future, when the Galileo
constellation becomes fully operational there will be two major GNSS constellations, a factor that will
contribute to increase even more the availability, the precision and the accuracy of systems built on
GNSS technology.
Road user charging systems and value added services, such as traffic management, are considered
liability-critical applications. A key factor for the acceptance of GNSS on these types of road
applications is position integrity. As already demonstrated in previous projects (for example ADvantis),
Galileo/EGNOS integrity is an enabler for the usage of GNSS for liability-critical applications.
Along with integrity, EGNOS differentiators may represent an important enabler for the market
uptake. The most relevant differentiators are: integrity, better accuracy, service guarantee and
authentication.
GNSS shows several major advantages, namely the flexibility in setting up and update the tolling
schemes whenever required, the flexibility in changing/expanding the road network covered, the
ability to easily provide value added services and the lower infrastructure cost on complex road
networks when compared to other technologies.
Other important factors arise when managing traffic with GNSS, since it potentially contributes to:
GINA

Decrease congestion;

Increase traffic flow;

Brings benefits to the environment;

Decreases road maintenance costs.
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
150 of 151
This document has carried out an analysis of the user requirements for a GNSS-based Road User
Charging system.
It has looked at the needs of the three main categories of actor in the
EETS/CESARE architecture, namely End Users, Toll Chargers and Service Providers. It has considered
the needs not only of a pure RUC system, but also of one which would provide a variety of Value
Added Services and specified the requirements for examples of such services.
GINA is a
demonstration system and there are a number of aspects of a live system which it will therefore not
be able to demonstrate or address. Nevertheless, the analysis of user requirements has looked
beyond the requirements of a demonstration system and documented some of the requirements of a
live system.
As with all systems, there are trade-offs between different requirements – not all can be satisfied
simultaneously. In particular, for an RUC system, there is a trade-off between privacy requirements
and the services that such a system can provide – the higher the level of privacy, the more
restrictions there are on the handling of data and the more difficult it is to provide certain services,
with some not being possible to provide in some cases. This document has analysed this trade-off,
with particular reference to the requirements of the Dutch government for the ABvM RUC system.
One of the key difficulties with specifying RUC systems is the specification of performance
requirements, to simultaneously ensure that users do not get overcharged and that service providers /
toll chargers get the revenues that they expect. In this area, measures of charging accuracy,
charging integrity and charging availability (analogous to the navigational parameters of accuracy,
integrity, continuity and availability) are being developed by GMAR and this latest thinking has been
utilised in analysing the end-to-end performance requirements for GINA.
Whilst the user requirements have been based around those for the proposed Dutch ABvM RUC
system, they are not identical. For example, the requirements for tariff structures are more widely
drawn in recognition of the fact that other countries may have different approaches and to
demonstrate that GINA is applicable to a wide variety of tariffing approaches. Conversely the Dutch
requirements include the integration of DSRC into the OBU for compliance purposes; as compliance is
not core to a demonstration of RUC, this requirement is omitted from the GINA user requirements,
although it has been included as an optional requirement for a live system.
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements
Code:
Date:
Version:
Page:
D2.1
15/09/2009
2.0
151 of 151
END OF DOCUMENT
GINA
GNSS for INnovative road Applications
State of Technology and End-User Requirements