Expert Group 9 Specification of the EFC application based on satellite technologies

Expert Group meeting 22-Mar-06


Expert Group 9Specification of the EFC

application based on satellite technologies

Ian Catling

Ian Catling Consultancy


EG9 members• Ian Catling, Ian Catling Consultancy, UK • Wolfgang Beier, DaimlerChrysler Services, Germany• Patrick Bustraen, Transics, Belgium• Ulrik Karlsson, Sweco, Sweden• Miroslav Marc, Agencia Griva, Slovenia• Franz Mühlethaler, PTV Swiss, Switzerland• Ken Perrett, Rapp UK, UK• Miroslav Svitek, Czech Technical University, Czech Republic• Jan Willem Tierolf, Rijkswaterstaat, the Netherlandswith informal input from • Erich Erker, Siemens, Austria


Content of presentation

• Organisational architecture• Charge system definition• Functional solutions• Assessment• Overview of recommended solution• Other aspects of the EG9 remit• Conclusions


Organisational architecture

Interoperability management

EETS provider Toll charger

User


Charge system definition (1)Basic scheme types

• Measured distance• Road segment • Closed network toll• Cordon charge• Area charge• Time-based charge


Charge system definition (2)Proposed EFC scheme categorisation

basic toll schemes

zone basedschemes

road segmentbased schemes

areatoll

time-basedtoll

road segmenttoll

closed network toll

cordontoll

measureddistance toll


Functional solutions (1)Fundamental issues

• With which entity does the OBE communicate?

• What data is reported by the OBE?


Functional solutions (2)Four main solutions

1. Permanent location reporting to the EETS provider

2. OBE reports the same data in all systems to the local Toll Charger• Three sub-options based on level of data aggregation

3. Each local Toll Charger specifies the data to be reported to the Toll Charger by all OBE• Two sub-options: standard application and software

download capability4. The OBE communicates primarily with the EETS

provider, who provides charge data to each Toll Charger as required


Functional solutions – main data flowsOption 1


Functional solutions – main data flowsOption 2a – “thin client”


Functional solutions – main data flowsOption 2b


Functional solutions – main data flowsOption 2c


Functional solutions – main data flowsOption 3a – “intelligent client”


Functional solutions – main data flowsOption 3b


Functional solutions – main data flowsOption 4 – “OBE proxy”


Assessment (1)Criteria

• Supporting competition • Supporting value-added services• OBU using standard in-vehicle

components• Privacy protection • Integration with other parallel toll services• Supporting many modes and technologies

for communication • Supporting many modes and technologies

for positioning • Volume-efficient communication• Avoiding system complexity• Subsidiarity principle (flexibility in defining

the toll scheme)• Economically efficient• Charging accuracy

• System reliability• Maintainability• Openness to technical progress• Consistency of business model• User friendliness• Fraud resistance• Enforcement flexibility• System control• Assignment of financial risks• Update effort• Ability to adapt to changing

requirements• Time for standardisation• Testability• IPR• Acceptability to toll chargers


Assessment (2)• Each solution scored against each

criterion• Criteria weighted to give weighted scores

for each solution• Objective process as far as possible, but

necessarily includes some subjectivity• Three solutions identified for more

detailed assessment:– 2a, thin client– 3a, intelligent client– 4, OBE proxy


Assessment (3)Option 2a, thin client

Advangtages• Simpler OBE software and certification• OBE maintenance easier (based on

greater simplicity of OBE)• Few toll data downloads (only need toll

context boundaries) • Toll chargers do not need to provide

detailed toll data • Simple to change toll schemes without

downloads

Disadvantages• Consequences for existing and future toll

chargers and their operations (i.e. they must implement CE-based charge calculation)

• Higher communication upload volume needed • No real time information for the driver• Privacy issues (i.e. toll charger’s central

equipment will receive itineraries of EETS-equipped vehicles)

• Enforcement and dispute settlement issues – complexity of roles (i.e. OBE records do not show directly whether or not the charging and location data are consistent)

• Limits opportunities for taking advantage of certain possible advances in future in-vehicle technology (e.g. on-board road link identification)


Assessment (4)Option 3a, intelligent client

Advangtages• Supports all existing and envisaged EFC

schemes• Minimal requirement for toll chargers to modify

existing systems• Enables the toll charger to tune EETS operation

to his exact requirements• Supports privacy requirements (i.e. depending

on the toll charger’s scheme, detailed location data need not be transmitted to the toll charger)

• Real-time driver feedback possible (i.e. the OBE has the capability to provide information to the driver according to the toll charger’s requirements)

• OBE capable of supporting toll chargers’ enforcement requirements

• High level of overall system reliability due to distributed system (i.e. the OBE has autonomous capability and can continue to operate even if the central system is unavailable)

• Provides a method for each toll charger to migrate his system (flexibility of OBE allows for system upgrades)

Disadvantages• More complex OBE software (OBE must

include range of capabilities based on standard EFC transactions as defined in MISTER and ISO 17575)

• Possibly higher development and certification costs

• Need for timely toll data download (when operating other than in location-reporting mode the OBE must have received full and up-to-date toll data from the current toll charger)


Assessment (5)Option 4, OBE proxy

Advangtages• Allows maximum flexibility in system

design (toll charger provides specifications to EETS provider)

• Toll chargers do not have to make any modifications to their local systems for charging

• Greater provision for competition between EETS providers

• No need for standardisation of OBE-CE interface for EETS units (each EETS provider can implement his own interface, which may be proprietary)

• Open to advances in location technology (EETS providers can implement new technology as it becomes available)

• Easier to add value-added services

Disadvantages• More complex OBE software (OBE must

include range of capabilities based on standard EFC transactions as defined in MISTER and ISO 17575)

• Possibly higher development and certification costs

• Need for timely toll data download (when operating other than in location-reporting mode the OBE must have received full and up-to-date toll data from the current toll charger)


Assessment (6)

• EG9 concluded that the optimum solution for the EETS is the “Intelligent Client” solution

• This imposes the least additional requirement on toll chargers’ systems, and

• is the most likely to be able to support toll chargers’ enforcement regimes without significant modification.


Overview of recommended solution (1)Range of possible charge processing division between OBE and CE


Overview of recommended solution (2)

• Security: trusted security module, the Provider Identification Module (PIM)

• Enforcement: EETS OBE acts identically to local OBE

• DSRC: EETS OBE includes DSRC for DSRC-based EFC, enforcement and augmentation


Other aspects of the EG9 remit• HMI: minimum requirements specified• Positional accuracy:

– Three types of requirements identified (geo-object recognition, absolute positional accuracy and distance measurement)

– Need for tests to be defined• Integration with other ITS services:

– Recommended solution will support other services

– Recommended that EETS interoperability management should manage contact details for e-Call and special fleet monitoring


Conclusions• Categorisation scheme proposed for EFC schemes• The recommended functional solution for the EETS is the

‘Intelligent Client’, which will provide and support all the requirements for the EETS

• EETS OBE should include a trusted security module (PIM)• Minimum HMI provisions for EETS OBE are proposed• Minimum locational accuracy requirements are proposed• e-Call, hazardous goods monitoring, livestock management

and other ITS applications can be provided by EETS Providers, with some support from the overall EETS interoperability management

• EG9 solution can be refined when procedural issues are decided

• Need to investigate IPR situation• Resources needed to specify the EETS in detail• Revised version of MISTER submitted, but still incomplete• Need for test specifications to be developed


The task split between EETS Provider and

Toll Charger is still under discussion customer relation

OBU provisioningOBU maintenance

initial OBU data loading algorithm of charge object detection

provisioning for updates of EFC sectors data provisioning for update of EFC context data

compilation of EFC context data compilation and provisioning for tariff relevant data

limiting OBU enforcement certificates operation of augmentation beacons

operation of enforcementremittee of fees paid by the EETS Provider

settlement with road owner

EETS Provider

Toll Charger


beneficial task split between EETS Provider and Toll Charger to achieve minimum

operation costs

customer relationOBU provisioning

OBU maintenance initial OBU data loading

algorithm of charge object detection provisioning for updates of EFC sectors data

provisioning for update of EFC context data compilation of EFC context data

compilation and provisioning for tariff relevant data limiting OBU enforcement certificates

operation of augmentation beaconsoperation of enforcement

remittee of fees paid by the EETS Providersettlement with road owner

EETS Provider

Toll Charger

recommendation

(standardized including context data format)


during operation DSRC and GNSS/CN systems are equal for the EETS Provider

Most of the actors and roles are common in DSRC and GNSS/CN systems

EETS Provider Toll Charger

GNSS/CNOBU

DSRCOBU

initializationpersonalizationinitial data/parameter context data (charge object configuration)

usage datablacklists

DSRCbeacon network

claimremittanceblacklists

Expert Group 9 Specification of the EFC application based on satellite technologies

Documents

Transcript of Expert Group 9 Specification of the EFC application based on satellite technologies