expert group 9 specification of the efc application based on satellite technologies
DESCRIPTION
Expert Group 9 Specification 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 - PowerPoint PPT PresentationTRANSCRIPT
Expert Group meeting 22-Mar-06
Expert Group meeting 22-Mar-06
Expert Group 9Specification of the EFC
application based on satellite technologies
Ian Catling
Ian Catling Consultancy
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
Content of presentation
• Organisational architecture• Charge system definition• Functional solutions• Assessment• Overview of recommended solution• Other aspects of the EG9 remit• Conclusions
Expert Group meeting 22-Mar-06
Organisational architecture
Interoperability management
EETS provider Toll charger
User
Expert Group meeting 22-Mar-06
Charge system definition (1)Basic scheme types
• Measured distance• Road segment • Closed network toll• Cordon charge• Area charge• Time-based charge
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
Functional solutions (1)Fundamental issues
• With which entity does the OBE communicate?
• What data is reported by the OBE?
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 1
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 2a – “thin client”
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 2b
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 2c
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 3a – “intelligent client”
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 3b
Expert Group meeting 22-Mar-06
Functional solutions – main data flowsOption 4 – “OBE proxy”
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
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)
Expert Group meeting 22-Mar-06
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)
Expert Group meeting 22-Mar-06
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)
Expert Group meeting 22-Mar-06
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.
Expert Group meeting 22-Mar-06
Overview of recommended solution (1)Range of possible charge processing division between OBE and CE
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
Expert Group meeting 22-Mar-06
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
Expert Group meeting 22-Mar-06
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)
Expert Group meeting 22-Mar-06
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