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

2. Expert Group 9Specification of the EFC application based on satellite technologies Ian Catling Ian Catling Consultancy

3. 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 Netherlands with informal input from • Erich Erker, Siemens, Austria

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

5. Organisational architecture Interoperability management EETS provider Toll charger User

6. Charge system definition (1)Basic scheme types • Measured distance • Road segment • Closed network toll • Cordon charge • Area charge • Time-based charge

7. basic toll schemes road segment based schemes zone based schemes area toll cordon toll closed network toll time-based toll measured distance toll road segment toll Charge system definition (2)Proposed EFC scheme categorisation

8. Functional solutions (1)Fundamental issues • With which entity does the OBE communicate? • What data is reported by the OBE?

9. Functional solutions (2)Four main solutions • Permanent location reporting to the EETS provider • OBE reports the same data in all systems to the local Toll Charger • Three sub-options based on level of data aggregation • 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 capability • The OBE communicates primarily with the EETS provider, who provides charge data to each Toll Charger as required

10. Functional solutions – main data flowsOption 1

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

12. Functional solutions – main data flowsOption 2b

13. Functional solutions – main data flowsOption 2c

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

15. Functional solutions – main data flowsOption 3b

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

17. Assessment (1)Criteria • 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 • 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

18. 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

19. Assessment (3)Option 2a, thin client 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) 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

20. Assessment (4)Option 3a, intelligent client 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) 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)

21. Assessment (5)Option 4, OBE proxy 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) 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

22. 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.

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

24. Overview of recommended solution (2) • Security: trusted security module, theProvider Identification Module (PIM) • Enforcement: EETS OBE acts identically to local OBE • DSRC: EETS OBE includes DSRC for DSRC-based EFC, enforcement and augmentation

25. 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

26. 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

28. The task split between EETS Provider and Toll Charger is still under discussion EETS Provider customer relation OBU 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 beacons operation of enforcement remittee of fees paid by the EETS Provider settlement with road owner Toll Charger

29. beneficial task split between EETS Provider and Toll Charger to achieve minimum operation costs EETS Provider customer relation OBU 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 beacons operation of enforcement remittee of fees paid by the EETS Provider settlement with road owner (standardized including context data format) Toll Charger recommendation

30. Most of the actors and roles are common in DSRC and GNSS/CN systems during operation DSRC and GNSS/CN systems are equal for the EETS Provider claim remittance blacklists Toll Charger EETS Provider DSRC beacon network DSRC OBU initialization personalization initial data/parameter context data (charge object configuration) usage data blacklists GNSS/CN OBU