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