Click on any title to view further details / The entire chapters are also available in PDF in the 'Download' section.

1- Introduction to EETS
(European Electronic Toll Service)

1.1 Directive 2004/52/EC

Member States of the European Union are willing to extend or implement toll collection on their roads, especially for trucks. Such extension at a European level needs to be harmonized as individual and specific toll systems implemented in each country would create inacceptable barriers to exchange within the EU and over-costs for implementing non standardized systems.

Therefore the European Union has defined, through the Directive 2004/52/EC, a new service called EETS (European Electronic Toll Service) in order to develop a strategy of convergence of electronic fee collection (EFC) systems, using standardized technologies, available to all stakeholders on a non-discriminatory basis.

European citizens should be enabled accessing to EETS by subscribing a single contract, complying with a contractual set of rules allowing all operators and/or issuers to provide the service, giving access to the whole network with a single On-Board Equipment (OBE) in each vehicle to identify the vehicle and the contract to pay tolls. The link between the OBE and the tachograph remains optional.

The directive has focussed on satellite technology (linked at that time to the Galileo project), the flexibility of which would allow different tolling policies, and a Dedicated Short Range Communication (DSRC) system based on 5.8 GHz frequency using two standards: one applicable only in Italy and the other defined by CEN applicable in all other countries and as a complement to satellite tolling (enforcement and augmentation). However some important legal, commercial and organizational aspects are missing, in particular the business model and the risk management.

The Commission has explicitly introduced the principle that the technology used for EETS could open opportunities to other services, with respect to privacy regulation for personal data collection.

Implementation of EETS was subject to a decision of the Commission (see below) giving a detailed description of the conditions which have to be fulfilled for its implementation.

The directive made a clear distinction between heavy goods vehicle (HGV) (including busses) over 3.5 tonnes and other vehicles. Implementation of EETS should have taken place three years after the adoption of the decision mentioned above for HGV and five years for all vehicles.

However EETS is defined in the directive (article 1.3) as a complementary service to local toll schemes, enabling consequently discrepancies between local operators and EETS providers, and barriers of several natures for implementing EETS interoperability by creating a competition between EETS and local subscriptions.

1.2 Decision 2009/750/EC

The Decision 2009/750/EC has been taken by the Commission in accordance with the directive 2004/52/EC, giving details on how EETS should be implemented.

The decision refers to a business model involving four main roles:

1. The Toll Charger (TC), in charge of defining the toll scheme rules and tariffs;

2. The EETS Provider (EP), in charge of bearing interoperability and providing the EETS service: one user contract for the whole network, one OBE and one invoicing cycle;

3. The Service User (SU), liable for tolls, who signs the contract with the EP and pays to the EP the toll according to its consumption and the invoices issued by the EP;

4. The (national) Conciliation Bodies, in charge of mediation between EP and TC regarding the application of the EETS rules in its country (no European entity in charge of such role).

The decision defines the rights and duties of EP's, TC's and SU's regarding EETS:

1. EP rights and duties are defined through the provisions 3 and 4 as following:

a. EP's have to be registered in the Member State of their residence (meaning that EP's need to be established inside the EU) according to common criteria defined in the article 3 of the Decision and Member State corresponding regulation;

b. EP's have to cover the whole EETS network within 24 months after registration. Nothing is said if an EP fails to cover the whole network, however that requirement has been raised by AETIS and Member States as a difficulty to implement EETS. The EP has to make an annual declaration to its Member State of registration, of its EETS domain coverage;

c. EP's have to self-control the quality of their service and guarantee the right personalization of the OBE ( Vehicle Classification Parameters) according to the data given by the SU for each vehicle;

d. EP's keep updated a list of invalid OBE's which is transmitted to the TC's;

e. EP's have to publish their contractual conditions for SU's to subscribe to EETS and the invoices have to clearly distinguish tolls and service fees of the EP;

f. EP's have to inform as quickly as possible their SU if a Toll Declaration has been missed in order to allow regularization before being sanctioned;

g. EP's have to cooperate with TC's with regard to enforcement in respect of privacy regulation.

2. TC rights and duties are defined through the provision 5 as following:

a. TC's have to establish and update a Toll Domain Statement which defines the main rules applicable to its Toll Domain and the general conditions for EP for accessing their toll domains;

b. TC's have to accept on a non-discriminatory basis, any registered EP requiring to offer EETS on its toll domain;

c. TC's have to accept any operational and certified OBE from EP's with whom they have contractual relationships, which do not appear on a list of invalidated OBE. The question of OBE certification which is mentioned here is not clear enough and needed more work during the REETS project;

d. TC's need to implement a degraded mode in case of EETS malfunctioning due to the TC, allowing SU's to continue their travel without significant delay and without being considered as toll evaders;

e. TC's have to cooperate with EP's, manufacturers and/or notified bodies in order to assessing the Suitability for Use of Interoperability Constituents on their toll domains.

3. SU rights and duties are defined through the provision 9 as following:

a. SU's may subscribe to EETS through any EP, regardless of nationality, state of residence or the state in which the vehicle is registered;

b. SU's shall ensure that all user and vehicle data they provide to the EP are correct;

c. SU's shall take all possible measures to ensure that the OBE is operational whilst the vehicle is circulating within an EETS domain and operate OBE in accordance with the EP's instructions, in particular as these apply to the declaration of variable vehicle parameters;

d. The payment of a Toll by an SU to its EP shall be deemed to fulfil the SU's payment obligations towards the relevant TC.

Member States play a major role in checking the capacity of a service provider to become an EP. They have to keep the list of registered EP's in their country and for each of them the toll domain which is covered.

Member States have also to publish the Toll Domain Statements for each TC in its country and designate the members of the Conciliation Body in charge of mediating between TC's in its country and any registered EP.

Toll Domain Statements contain in particular the Toll Context Data which defines information necessary to establish the toll due for circulating a vehicle on a particular Toll Domain and conclude the Toll Transaction and the consistence and the rhythm of provision of the Toll Declarations (statement to a TC that confirms the circulation of a vehicle in a Toll Domain in a format agreed between the EP and the TC).

1.3 Interoperability Constituents

The provision 14 of the Decision 2009/750/EC and its Annexes 2 and 4, have tried to set conditions which should be fulfilled by Interoperability Constituents in order to be accepted in any Toll Domain. In particular the Annex 4 of the decision, is presumed defining the condition to set Conformity to Specification and Suitability for Use in order for Interoperability Constituents to operate in a Toll Domain.

During the REETS project, the acceptance procedure of Interoperability Constituents has been more precisely defined. However procedures have still to be partly or totally duplicated in every toll domain which remains an important initial cost.

1.4 Application guide to implement the Decision

A Guide has been established by the Commission in order to facilitate the implementation of the Decision 2009/750/EC and the directive, commenting several provisions written in the regulations. The guide has been used through the REETS project and the findings of the project stand in for the guide which is not commented here.

1.5 AETIS Position paper

EETS implementation was delayed much longer than expected by the Commission and the EU Council. AETIS has explained many times that the actual regulation fails to define a business context which make EETS affordable to service providers. The Commission launched therefore the REETS Project in order to start interoperability where stakeholders are willing to start and check during the project where short stopper should be removed or changes to be made in the regulation.

AETIS has been contacted (as other professional organizations) in order to produce a Position Paper explaining the difficulties which would hinder deployment of EETS. AETIS position is summarized as following:

In its Position Paper, AETIS has pointed out the importance of the registration process and its yearly renewal, which would establish the founding principles of a trustful relation between EP's and TC's.

The way risk management is fairly shared and compensated between the stakeholders, remains a key issue for EETS sustainability.

Potential unfair competition between local EFC services and EETS is not acceptable, and EETS should be considered, with regard to the objective of the Commission as a universal EU service.

The services rendered by the EP should be fairly remunerated, with affordable payment terms, to allow the development of EETS and the sustainability of the business.

A European organization should be in charge of interoperability management , with regard to all stakeholders' interoperability constituents (including those implemented by TC's) and regulate the acceptance process of interoperability constituents all over the EETS Toll Domain.

2- EETS Business model

2.1 Main actors of EETS

EETS business model involves mainly a contractual relation between the following parties:

1. The Toll Charger (TC), in charge of defining the toll scheme rules and tariffs and providing the motorway service;

2. The EETS Provider (EP), in charge of providing the OBE, bearing interoperability on the EETS Toll Domain, collecting and guaranteeing the toll due by its customers to the relevant Toll Chargers;

3. The Service User (SU), liable for tolls, who signs the contract with the EP and pays to the EP the toll according to its consumptions and the invoices issued by the EP;

4. The Manufacturer who provides the Front End, composed by the OBE and the proprietary software needed to manage the OBE.

The contract between the TC and the EP aims at defining the conditions for the acceptance of its Front End for collecting the tolls due for the road service operated by the TC to the benefit of the Service Users. The SU vehicle and the EP data incorporated in the OBE allows the TC to identify the user liable for tolls, the tariff applicable to its vehicle and the EP in charge of paying tolls. The OBE makes therefore the link between the three contractual relations: between the SU and the TC for using the tolled road, the SU and the EP for the toll payment, and the EP and the TC for the OBE acceptance.

Where the OBE is in the Exception List of invalid OBE, the contractual link is broken and the EP has no more obligations to pay tolls for the eventual use of such OBE.

The EETS business model is based on trustful relations between the actors, provided certain conditions are reached.

2.2 EP Registration

The establishment of the trustful relationship between EETS actors is mainly based on the Registration Process of an EETS Provider in its Member State of residence, which evaluates the company registering as an EETS Provider with regard to its financial, technical and operational capabilities to fulfil the requirements set out in the EETS Directive. Registration is reviewed by the Member State of residence on a yearly basis. Criteria for registration are defined by the national regulation with respect to the conditions defined in the article 3 of the Decision 2009/750/EC.

It should be noted that at the stage of the first registration the EP commits itself to use the Front End which is submitted to the registration authorities but has no obligation to have implemented it.

The EU regulation is actually not sufficient to define a harmonized process of registration, de-registration and re-registration of EP's, which might lead to discrepancies and misunderstandings between Member States. Additionally no analysis has been made of the consequences, at a European level, of de-registration of an EP (for financial reason, for instance). The REETS project does not bring answers to that question.

2.3 Acceptance procedure

The acceptance procedure consists in checking and testing that Interoperability Constituents set in place by both the EP and the TC are able to exchange data in order to perform the toll collection in compliance with TC's expectations. In reality the acceptance procedure mostly focusses on the EP side which has to provide a Front End which satisfies the TC's requirements.

The acceptance procedure starts at the Manufacturer's level with the demonstration that the Front End complies with the European standards and the EETS general requirements.

The registered EP will have to follow, with each TC, an Accreditation Procedure which covers all technical, procedural and contractual steps to be followed by the EP's Front End to be accepted in the TC's Toll Domain for toll transactions. It includes the certification of compliance to EETS specification established by the Front End Manufacturer, the Suitability of Use tests performed for the OBE after personalization by the EP and the contractual agreement between the EP and the TC.

The conditions for accreditation should be formally and securely described by the TC at the very start of the contractual discussions. This should also include how modifications made by either party in the Interoperability Constituents may require additional testing.

The Accreditation Procedure has not been viewed at a European level and some TC specificities may hinder immediate interoperability without adaptations of the Front End. Even though end-to-end tests need to be done before operating the Front End and the data exchange protocols in a new toll domain, a debate remains open whether the EP or the TC (with the EP cooperation) should lead the Suitability for Use tests. In reality the Accreditation Procedures to be followed in all the EETS Toll Domains will consume a lot of time and money for the EP. REETS has not provided the right solution to improve the accreditation procedure.

2.4 Guarantees

Protection of TC's revenues is a major prerequisite to the acceptance of a third party (EP) between the TC and the User. The risk of loss of revenue of a TC may only appear if the EP falls into insolvency at a European level. This situation will concern several months of toll revenue on all the EETS Toll Domain and for all the users equipped by the defaulting EP. The actual response, in the Decision, to such a situation is to require from the EP to present a guarantee of one month of turnover, the form of which may differ from one TC to another.

Introducing the one month turnover bank guarantee concept in the Decision has given a false solution for mitigating EETS Provider insolvency risk and introduced costs and constraints which might hinder the deployment of EETS. Additionally, the EP may face different time of renewal of credit protection tools to cover the EETS Toll Domain, which is an additional administrative burden.

Registration and its annual review by a Member State is a first step financial guarantee that the EP has the financial capability of providing the service European wide. But no procedure has been defined on the case where the EP does not meet anymore the financial requirements to be an EETS Provider.

AETIS proposes to ask rating agencies to follow the level of risk of EETS Providers analysing the yearly accountings and using evaluation criteria which could be fixed in a new decision such as the level of shareholder capital compared to the level of investment and level of equity compared to the average exposure of unguaranteed outstanding tolls (toll turnover due to the Toll Chargers which is not covered by a bank guarantee, a risk insurance or a deposit). [1]

This topic remains open and no solid solution has been brought out for the moment.

2.5 Contractual models

2.5.1 VAT issues

VAT rules have to be understood in order to apply the right contractual model. In particular, Toll has to remain linked to the corresponding infrastructure, all along the business chain, in order to be submitted to the VAT rules of the country where the toll is due. The chain of contracts ruling the EETS business complies with the following rules:

· Tolls are either not subject to VAT where toll is a tax or subject to the VAT rules of the country where the toll is due. The VAT regime of tolls has to be kept all along the business chain;

· Remuneration paid by TC to EP is subject to the VAT rules of the country of residence of the EP and should therefore not be mixed with toll invoices;

· Service fees paid by EP's customers to the EP are subject to the VAT rules of the country of residence of the customer and should therefore be separate from the toll invoices.

2.5.2 Contracts between TC and EP

Three models of contract are possible between the TC and the EP: the Reselling Model, the Agency Model and the Customer Mandate model.

In the Agency Model, the EP represents the TC in its relation with its customers and should apply the terms and conditions defined by the TC for invoicing tolls. The EP is invoicing tolls in the name and on behalf of the TC. Such model is compliant with the VAT rules however the invoice is issued in the name of the TC which makes legal recovery of the amount due by customers impossible by the EP. In principle, such model would not allow the EP to guarantee tolls to the TC and would need as many contracts with customers as contracts with TC. This model is consequently not compliant with EETS regulation where the customer should have a unique contract with the EP. The Agency Model is therefore not compliant with EETS and should be rejected.

The Customer Mandate model should only be used where toll is a tax. The TC is sending to the EP a statement of the toll due by its customers, users of the tolled road subject to tax. The statement is not an invoice as the EP is not liable for the tax. It is an accounting piece allowing the EP to pay the tax on behalf of its customers and recovering the corresponding amount from its customers, according to the mandate the EP has been given by its customer. The customer name has to be known by the TC and the mandate given to the EP sent to the TC. Such model would have been used for the French Ecotaxe.

The Reselling Model should be used as a general model for EETS toll collection . The EP will receive an invoice from the TC covering the whole amount of tolls due by all its customers and the EP would split the total amount by its customers and invoice the corresponding tolls in its own name and on behalf of the TC. EP service fees are put in a separate invoice. This would keep the VAT rules applicable to Tolls all along the business chain, even if the EP has no direct relation with the final user, when for instance the EP works with another intermediary. Only one contract between the customer and the EP may cover the EETS Toll Domain, in compliance with the EETS Directive. The final user may also sign the contract with an intermediary which is in business relation with an EP and guarantees the full EETS coverage through the EP.

In all the business models, the EP should have reasonable payment terms to collect tolls from its customers before repaying the TC.

Except for the Agency Model, the EP needs to be tax registered in each country where toll is collected and to issue distinctive toll invoices per country.

In the reselling model, the end user is, in principle, not known by the TC. In the other models, user registration should be harmonized at a European level in order to facilitate the collection and the transmission of the user's documents.

2.5.3 Clustering initiatives

Clustering of business actors may facilitate the EETS deployment:

- On the TC side, operation rules or even more data computing shared by several TC will ease the accreditation process of EP's and EETS operations;

- On the EP side, the holder of the Front-End may offer its facilities to other players which would then concentrate on customer services or/and contractual relations with TC's. The business on the EP side may have different aspects: Front-End investment and management, customer relations, TC contractual acceptance, which could be split in several actors contractually linked within the EP role.

2.6 Remuneration

The remuneration scheme should take into account the services which are rendered by either party involved in EETS to the other.

The services rendered by the EETS Provider to the TC have been identified by AETIS as follow:

1. Getting and keeping EETS Registration and managing administrative procedures in each EETS countries (such as tax registration) to ensure the business;

2. Managing successfully the accreditation procedure in each Toll Domain;

3. Providing to the users and personalizing the OBE for toll collection;

4. Operating the Front-End for toll purposes and taking care of the aftersales service of the OBE (including OBE renewal and OBE failure process management);

5. Operating the back-office to back-office data exchange platform with the Toll Charger;

6. Exchanging exception lists of invalid OBE;

7. Providing the toll declarations where applicable;

8. Monitoring the whole system to comply with Toll Chargers requirements and KPI's;

9. Investing on interoperability constituents to comply with the Toll Charger requirements and its evolutions;

10. Managing the risks related to the contract signed with the Toll Charger, especially with regard to the eventual penalty schemes which could be included in the contract or even loss of toll revenue that could be asked for to the EETS Provider;

11. Managing the contractual relation with the users: signing the subscription contract, explaining the toll scheme, helping for registration where required, pre-instructing claims or question from the users.

12. Invoicing and collecting the toll fees from the users, paying back the Toll Chargers within a time frame compatible with the toll recovery process from the users, and, if the terms of payment required by the Toll Charger are insufficient to recover money from the user before payment to the TC, taking into account the financial burden and risk of the upfront payment to the TC ;

13. Guaranteeing the payment of liable tolls due by customers and providing the Toll Charger with a credit protection tool;

14. Managing the subscription to the eventual discount schemes or loyalty scheme set in place by Toll Chargers which should be accessible to EP customers as well as to national operators' customers at the same conditions.

On the TC side, the annex 1 of the Decision allows the TC to ask for payment to the EP for fixed charges imposed on EETS Providers based on the costs for the Toll Charger to provide, operate and maintain an EETS compliant system in its toll domain when such costs are not included in the toll. This would cover:

1. Managing the accreditation procedure of the EP;

2. Managing the risk related to the contract signed with the EP;

3. Operating and maintaining the back-office to back-office data exchange platform;

4. Keeping EETS compliance of TC equipment.

However such costs borne by the TC could also be considered as part of the EETS legal obligations and consequently included in the tolls.

All kinds of "entrance fees" (fixed charges, including suitability for use costs, imposed on EP's) are considered by AETIS as a barrier to start the service in a toll domain, and a potential discrimination with national operators acting on a local scheme.

Business models on EP remuneration are generally considering a fee in proportion of the toll collected and a fixed fee remunerating the provision of the OBE. Remuneration rules should be defined in bilateral contracts on a non-discriminatory basis which includes the remuneration of local actors on local schemes.

Remuneration rules have to be published by the TC in its Toll Domain Statement.

2.7 Enforcement

Enforcement falls under the sole responsibility of the TC and the EP should not be held for payment of fines of any kind applied to toll evaders. However the toll scheme may apply flat fees where toll cannot be exactly determined, due to the user's behaviour. Such fees remain part of the toll scheme and EP have to collect them.

The article 4 of the Decision sets an obligation to the EP to collaborate with Toll Chargers in their enforcement efforts, with the limits of privacy laws.

The EETS enforcement process cannot lead to facilitating identification of toll evaders just because the EP is contractually connected to the end user.

2.8 Table of content of the EP/TC contract

The main topics which should be included in the contract to be signed by the TC and the SP have been identified in the chapter 5 of the REETS D1.1 report and are summarized hereunder:

1. Information about the contracting parties.

2. Definitions

3. Purpose and Scope of the Agreement Includes also reference to any legal acts or documents, pursuant which the contract is established

4. Acceptance procedure, main obligations of the EP and the TC, data exchange procedures, change management, KPI measurement procedures/Service Level Agreements

5. Economic and Financial Issues including EP remuneration, payment terms and currency, contractual model used for toll invoicing, credit protection tool, discount schemes and loyalty programs, penalties when agreed on quality parameters

6. Customer Service: registration where required, complaints and claims

7. Enforcement

8. Privacy and data protection

9. Confidentiality of contractual provisions

10. Publicity and Trade Mark Protection regarding intellectual property rights and the use of trademarks

11. Duration and termination of contract, withdrawal from the bilateral contract, breach of contract / liability, disputes / litigation procedures, adjustments to the bilateral agreement, applicable law and language and arbitration

12. Miscellaneous

13. Annexes: Suitability for use requirements, OBE requirements inclusive personalization, security policy, KPI definitions and measurement principles, minimum set of clauses for SU contract, claim handling procedures.

3- Risks

3.1 Risk management plan

EETS relies on a trustful relation between TC and EP to collect tolls. Therefore significant Risks have to be clearly identified, fairly shared between the actors and mitigated as far as possible. It has also to be reminded that the technical choice for the toll collection method (DSRC, free flow, satellite.) is made by the TC and therefore the TC has to accept the risks which are bound to its choice.

One of the major EP registration obligations is to establish and keep regularly updated a Risk Management plan, audited by a third party at least every two years and checked by the Member State of registration.

On the point of view of an EP, risks can be generated:

1. At a political level, by Member States or public authorities, through a change of law or a political decision;

2. Through its relation with a Toll Charger;

3. By the Manufacturer of the Front End and the quality of its products;

4. Through EP operations;

5. Through the market conditions;

6. Through non-EETS activities;

7. By the management of the company;

8. By users.

On the point of view of TC and/or Member States, the major risk consists in the bankruptcy of an EP which impacts not only losses of toll due by the EP all over Europe but probably also a significant population of users which would be temporarily without any valid OBE until they can switch to another provider. REETS has not really provided inputs to such a situation to explain how to anticipate and find mitigation measures for such a risk, but a fair remuneration of the services provided by EP is obviously a key mitigation issue.

AETIS recommends also that the financial level of risk put on the shoulders of the EP is at the level of its remuneration from the TC.

3.2 Political risks

Risk of change of national legislation, new compliance standards and incoherence or non-compliance between EU and MS legislation compromising the investment made by the EP, major political changes in tolling policy (e.g. Ecotaxe) are significant risks (every business fears the changes in legislation) which the EP, when working in several EU (toll domains) countries, is consequently exposed to more changes.

Member States need to take in consideration the dramatic consequences of political risks, which would affect all EU toll domains. No mitigation measures can be taken at the EP level.

3.3 Contractual risks in the relation with a TC

3.3.1 KPI's

The EP has to comply with contractual KPI's which qualifies its service. Failing to reach certain KPI's without being able to improve the service may lead to loss of tolls and disputes involving the EP system liability. The EP needs to carefully check its capability to reach the requirements set by the TC before signing the contract. Additional Road Side Equipment of the TC (such as Augmentation Beacons or Completion Check Communication equipment) could mitigate the risk on the TC side. AETIS has recommended not to link KPI's to a penalty scheme if the EP's good will to find solution is proven.

3.3.2 Delays in updating toll context data

Each TC may update toll context data at any time and as often as wished. However this is not neutral for the EP which would have to update the toll context data accordingly in its Front End. In operation the experience shows that at least three to six months would be necessary to have 80% of the OBE updated with a new toll context data file. TC's must be aware that the EP will not be able to change the toll context data for all EETS Toll Domains more than once a year and such change needs to be coordinated for all Toll Domains.

3.3.3 Technical changes

Technical changes imposed by the TC to the EP may need important modifications in the EP system which would have consequences on the accreditation on otherToll Domains and important financial impacts and delays to achieve full compliance in all impacted Toll Domains. Interoperability Management at a European level should play a role in mitigating such risk.

3.3.4 Delays in instructing the accreditation process

In the actual situation, the EP will have to pass as many accreditation processes as TC's (at least for the suitability for use step for clusters of Tc's). This means a lot of time spent before the accreditation process is fulfilled on the whole EETS Toll Domain, for a first accreditation as well as for the introduction of a modification in the EP's (or even TC's) Interoperability Constituents. The experience shows that the EP cannot correctly predict the time needed to achieve the process, and consequently cannot properly anticipate the technical, commercial and competitive impacts. AETIS has recommended that the EP keeps full control on the suitability for use step which needs to be carried out in all EETS Toll Domains at the same time.

3.3.5 Language interpretation

EETS Toll Domain covers various countries and various native languages. The documents are mostly established in the national language then eventually translated into other languages. This would clearly put a risk of misunderstanding linked to language understanding.

3.4 Technical risks of Manufacturer products

3.4.1 Investment

On the EP and the Manufacturer side, major investments need to be made in order to comply with EETS requirements in all Europe: Manufacturers need to be enabled to provide equipment which would be accepted all over Europe and EP need to get equipment that would work and collect toll in all European toll domains. In addition the EETS framework should also allow new technologies or new processes to be experimented without major barriers. The environment for such investments to be made needs to be clear, in order to have a full knowledge of the costs and risks taken by the Manufacturers and the EP.

3.4.2 Operations

The Front End consists in hardware and software designed by the Manufacturer in compliance with EU standards, EETS general specifications and EP additional requirements. The experience shows that software updates are needed at least once every year to improve the Front End quality and to correct bugs. Laboratory or small scale tests made by the Manufacturer or the EP may not be significant of the behaviour of the Front End at large scale, due to unpredictable real time behaviour. Updating software in operation presents therefore a high risk of regression and corruption of OBE in operation. Additionally the EP must be aware that OBE with different versions of software will coexist and be in operation at the same time, as the process of software update in all the OBE's takes even more time than a Toll Context Data update. Such update process must be carefully controlled by the EP in coordination with the manufacturer. Update solutions through OBE wire connection should be possible to accelerate the update process and mitigate the risk of an unexpected bug which would hinder the update by air.

3.5 Risks in operation

3.5.1 Front End management

The EP is in permanent dialog with all its OBE through the Front End application to know the status of all the OBE's (alive, travelling, blacklisted or reactivated, out of range, failing to respond.) and to update data and software inside each OBE. The experience shows that mistakes in application updates or in sending data, or loosing contact with OBE's are events that will occur in the life time of the Front End. Mitigating such risk through careful procedures belongs to the know-how of EP's running their own Front-End.

3.5.2 Toll Declarations in satellite toll schemes

In a satellite environment, the end responsibility for calculating the toll charges should stay under the TC role. The role of the EP should be limited to collecting positions within the toll domain and sending them to the TC. EP cannot realistically bear a heavy technical risk, associated with satellite tolling, when providing charging data or even more in calculating the toll fees. AETIS recommends therefore to limit the requirements to sending positioning data within the toll domain, with respect to the toll domain definition, with a frequency as defined by the TC.

3.5.3 Data exchange with TC

Invoicing correct toll is depending on the data exchange protocol set in place by both the EP and the TC. Even if such protocol refers to a common standard [3], complexity increases with the number of TC to exchange with and risks of recurrent dysfunction would lead to loss of revenue and over costs for failure handling. Additionally failure would also affect users' satisfaction and trust in the toll collection process.

3.5.4 Personalization and user registration processes

The EP is responsible for the correct personalization of the OBE with vehicle data received from the user. The EP needs to control the full personalization process in order to be able to prove that the OBE delivered to the user has been correctly personalized and that only one OBE has been personalized for the corresponding vehicle.

In certain toll domains, the EP is also in charge of communicating the registration documents of the user's vehicle to the TC. No harmonization for the set of documents to be provided has yet been done among the Member States. In case of a problem affecting the registration process, user's vehicle, already equipped with their OBE (because it may already be used in other toll domains), may find themselves in violation under penalty of a fine.

3.5.5 Synchronization in OBE acceptance

Deployment of EETS will show new questions regarding the acceptance of vehicles in all Toll Domains: it will be difficult, once the type of OBE and the EETS Provider are accredited somewhere, to synchronize on all the EETS Toll Domain the acceptance of the OBE and equipped vehicles. This will lead to situations which have not yet really been experienced and consequently new risks.

3.6 Market risks

3.6.1 Wrong estimate of the quantity of OBE needed

A first issue for EP running their own Front-End is to get a right estimate of the number of OBE to order to the Manufacturer, as OBE's are not standard products and re-starting a chain of production is not simple and generates high costs.

If the EP under-estimates the number of OBE, the EP may miss part of its market share being unable to deliver all the OBE to its potential customers. Yet cost of OBE provision decreases with the volume, which means that the EP may have delivery prices which are over the market prices.

If the EP over-estimates the number of OBE, it will generate a significant investment over-cost which here again may lead to a loss of market share due to higher prices for OBE delivery, considering that the experience shows that the market is quite tough and does not leave high margins.

Right estimate of the volume of OBE allows the EP to offer its best price on the market.

3.6.2 Market deterioration

Toll collection services are very competitive, prices are low, and margin are mostly dependant on the volumes of equipped customers. Additionally the experience shows that the level of prices is decreasing in time and customers are reluctant to pay for the service in addition to tolls, except if the service is linked to a discount scheme.

In such conditions there is a permanent risk of price dumping especially if the EETS offer can be combined with more profitable non-EETS services.

3.6.3 Discrimination or national market protection

The customer has always the choice of using the EETS service in a toll domain or the local service if this is more attractive to him. EETS is permanently in competition with local/national services. EETS needs therefore to be more attractive for the customer.

Additionally there might be some national/local specificities in delivering the service which would create a discriminatory situation between local providers and EP's.

Mixing TC activities and EETS provision in the same company should be strictly forbidden.

3.7 Other risks

3.7.1 Non-EETS activities

Service companies providing EETS services may have other non-EETS activities. The profitability of the company is dependent on the whole set of services it provides. The failure of some non-EETS activity may endanger the whole company and create a situation of critical risk on its EETS activity.

The risk management plan needs to identify such situation and mitigation measures which might be envisaged.

3.7.2 Internal risks, management risks !

Internal risks cover all the risks connected to how the company is managed, including the internal risk of fraud or malevolence.

3.7.3 Risks due to users

The EP has to cover the risk of non-payment of its customers and should be remunerated consequently.

The EP, in relation with the Manufacturer, has also to take all technical measures to prevent fraud on the OBE itself. Mitigation of such risks is made through both the hardware and the software of the OBE, security tools, statistical behaviour analysis and a careful control on the OBE delivery process.

3.8 Table of correspondence with D1.2 identified risks[4]

Risk #

Risk name

Risk category

AETIS correspondence and comments


Risk on Toll Charger (TC) or Member State (MS) decision(1) and/or change of legislation (2) impacting the EETS business (ex 1.: VAT law -> business impact ex 2: judgment of notified body affecting TC in another toll domains)

SP & TC Risk

§2: major risk for the EP with no mitigation measure at its level. Should be fully covered by the Member State


Risk of system (1a) or components (1b) unavailability or failure and risk of errors in road usage data (2)

SP, TC & SU Risk

§3.2: highly probable risk in satellite based toll collection


Risk of delays (1) and uncontrolled errors (2) of any change made in the OBE

SP, TC & SU Risk

§3.2: highly probable risk in satellite based toll collection


Risk of low quality service level of toll chargers (TC)

SP & TC Risk

§3.1: the quality of the EETS service may also be dependant to the TC quality of service


Risk of low service quality of service provider (SP)

SP & SU Risk

§3.1: KPI's must be reasonable and reachable by the EP and TC needs to take into account the constraint of its technical choices for toll collection


Payment risk regarding tolls of Service User (SU)

SP Risk

§7.3: EP should be remunerated for such risk


Payment risk regarding toll of SP

TC Risk

§1: linked to risk #8


Insolvency risk of a service provider (SP)

SP & TC Risk

§1: Major risk for all the EETS toll chargers


Risk of Toll Charger (TC) bankruptcy

SP & TC Risk

Not significant


Excessive failure rate of the OBE (software)

SP, TC & SU Risk

§4.2: The quality of the Manufacturer products (software and hardware) are key issues


Risk of investment

SP, TC & SU Risk

§4.1 and 6.1: Implementing its own Front-End generates a high capitalistic risk


Risk of fraud (1) by the users and by the Service Provider (SP) (2) or security failure

SP, TC & SU Risk

§7.2 and 7.3: such risks should not be under estimated


Risk of recurrent dysfunction in the TC/SP exchanges of the processes - single event

SP & TC Risk

§5.3: The suitability for use tests should focalize on data exchange, cluster of TC may mitigate the risk


Risk of market deteriorations (1) & discrimination or national market protection (2

SP Risk

§6.2 and 6.3: EETS business has low margin and is directly linked to volumes of OBE. Being an additional service to national schemes, discrimination with national market is highly probable

Risks not identified in the REETS D1.2 report

§3.3: technical changes

§3.4: delay in instructing accreditation process

§3.5: language interpretation

§5.2: toll declarations in satellite schemes

§5.4: OBE personalization and user registration

§5.5: synchronization in OBE acceptance

§7.1: non-EETS activities

4 - Technical issues

Interoperability constituents on the EETS Provider side are composed of the Front End which generates the Toll Declarations and the Back-End for all the data exchanges with the toll chargers back-offices.

4.1 The Front-End

4.1.1 The Front-End parts

The EETS Front-End components are the OBE and the Proxy (the software used to control and manage OBE’s). The communication between the OBE and the Proxy uses GSM/GPRS data link and is proprietary to the manufacturer of the Front End. The proxy software is shared between the OBE and the central system of the EETS Provider, depending on the technical choices of the Manufacturer. No standard defines the way data exchanges should be managed within the Front-End.

The Toll Context Data sent by the Toll Chargers are implemented in the proxy and could either be mainly centralized in the EETS Provider central system (the OBE behaves as a “thin client” to the central system) or distributed in each OBE which is then able to determine the Toll Declarations by itself (the OBE behaves as a “thick client” to the central system).

The OBE generates positions using at least two satellite positioning systems: GPS, Galileo or Glonas. The OBE operates also DSRC 5,8GHZ microwave technology compliant with CEN standards (15509:2007, 12813, 13141) and ETSI ES 200674-1:2012-08 standard for Italy. DSRC CEN technology is also used for satellite tolling and has to be implemented in a single unit managing both satellite and DSRC CEN technologies. The Italian DSRC standard may be implemented in a separate unit or merged in a single unit with the DSRC CEN and satellite technology parts.

The Front-End manages security mechanism to certify the reality of the Toll Declarations which are sent to the Toll Chargers and to fight against fraud and misuse of the OBE’s.

Key Performance Indicators have to be carefully followed by the EP in order to have quick reactions to any incident detected through its Front-End management system. Satellite tolling systems are dependent on the quality and the trust given to data generated by the Front-End. It has to be noted that due to the complexity of the hardware and the software and the number of distributed OBE, errors and failures are mostly probable. The risk management plan of the EP has to define mitigation measures to prevent major damage and costs in case of error or hardware failure. In particular, software updates (in the proxy and/or in the OBE’s) or data modifications in the OBE, which need to be regularly made (at least once a year!), may lead to dramatic consequences if not correctly mastered by the EP.

The procedures of acceptance of the Front-End by toll chargers are necessary but not sufficient to ensure that the EP is mastering all the processes needed to correctly manage the Front-End. The EP needs to carry out, with the help of the Manufacturer, a full set of internal procedures and tests and follow its own KPI’s, under its responsibility, that the EP considers sufficient to have confidence that the Front-End is properly managed.

4.1.2 The OBE

The OBE units are positioned on the bottom and the middle of the windshield of the HGV. The actual technology does not allow to have the size of the OBE compatible with light vehicle windshields except if limited to DSRC technology. DSRC units in light vehicles have to be positioned at the upper part and in the middle of the windshield behind the mirror. Special attention has to be brought on metalized windshield where DSRC waves do not get through. Vehicle manufacturers have in principle inserted a special zone where OBE units need to be placed. In the following only OBE for HGV are considered.

OBE unit dedicated to satellite positioning needs to be constantly powered either by a removable link to the cigarette lighter of the vehicle or directly connected to the battery (which is the preferred method). DSRC only unit (as for example a specific DSRC ETSI unit for Italy) are autonomously powered by battery. Some Manufacturers have separately powered by battery the DSRC CEN part from the rest of the OBE to keep a permanent access to the personalization data in the OBE – in case of failure of the OBE, the DSRC link may give access to data in the OBE and keep it operational for DSRC transactions.

Personalization data are displayed in several pages of parameters which are accessible from a DSRC reader. Vehicle parameters have to be copied (or accessed) identically in all pages. Each page represents one contract and one issuer of the contract. One page only is linked to the satellite part and data are copied into the CCC parameter page: only one service provider is recognized as providing services in satellite based tolling systems, where several service providers may provide access to different DSRC tolling networks, depending on agreements between the owner of the OBE and service providers partners.[1]

When passing a DSRC road side equipment, the TC will ensure at first that the type of OBE is accepted in its network, then read all identifiers of issuer/contract which are present in the OBE and check the first one which is accepted in its network. The RSE will dialog with the OBE using the page of parameters which corresponds to the first accepted identifier.

In a satellite based toll system, the DSRC link is used for enforcement (unique CCC table of parameters, which must contain the identifier of the EP accepted in the satellite toll network) and for sending geolocation positions where the GNSS is weak or not accessible (through so-called augmentation beacons). In all satellite tolling network, only one service provider is recognized as able to provide the service and its identifiers are set in the CCC table and used to dialog with augmentation and CCC beacons.

It should be noted that the precision of GNSS positioning (requiring at least to “see” four satellites at the same time) is mostly dependant on the chip installed in the OBE which should be chosen by the Manufacturer among the two or three major GNSS chip providers. Time of first fix is also important to get right positions immediately after the start of engine of the HGV where the OBE is installed.

Data transfer between the OBE and the Proxy uses the GPRS channel which is cheap in terms of hardware in the OBE and operating costs especially while roaming all around Europe. The SIM card inside the OBE should be welded and chosen with the highest manufacturing quality for the best time life of the telecom part of the OBE. A particular attention should be given by the EP when choosing the telecom operator as changing the SIM card inside the OBE has a very high cost and cannot reasonably be envisaged during the normal time life of the OBE.

DSRC security mechanisms are described in the ISO 15509 standard for signing DSRC transactions or granting access to the OBE.

In a DSRC toll domain, Toll Declarations are generated by the RSE and registered in the OBE. The TC keeps full control on the Charging Data and the EP may also get in real time the information registered in the OBE if such functionality has been implemented.

For satellite tolling purpose, the “thin client” OBE needs at a minimum to implement geographic zones with parameters of distance and time for generating and sending positions; it could also enable implementing “virtual gantries” over the road network where passing through generates an information sent to the proxy. Toll Context Data sent to a “thin client” OBE are set to the minimum and if the OBE is parameterized to send positions on a regular base to determine the location of the HGV wherever it is, the information way be sufficient to establish a good estimate of the toll due: this would minimize the risk of not updating in time the OBE with the right Toll Context Data. At the contrary, a “thick client” OBE needs to be updated before it is used in a toll domain, which might become an unaffordable constraint for the EP, especially if new Toll Context Data are sent by several TC at different times in the year. It should be noted that to update correctly 80% of the OBE will take several months, due in particular to the weak debit of GPRS! And EP needs to keep control on all its OBE’s and get regular information of their locations: the “thick client” OBE seems therefore not really adapted to the EP needs and constraints.

Finally a particular attention has to be brought to the average number of failing OBE per year which will be significant (independently from the choice of the Manufacturer). The process for exchanging faulty OBE is complex and managed at a European wide scale, with variable consequences for the user depending on the flexibility of the TC for determining tolls until the failing OBE could be exchanged.

4.1.3 The Proxy

The main functionalities of the Proxy are:

  • Getting the Toll Context Data and making the right interpretation of them in the context of the Front-End which the EP has implemented;
  • Sending data to the OBE to implement the Toll Context Data part dedicated to the OBE and updating them when ever needed;
  • Sending personalization data to the OBE to link the OBE with a specific vehicle and add if necessary new pages of contract;
  • Updating the OBE software (in practice the experience shows that it is needed at least once a year);
  • Receiving charging data from the OBE and interpreting them before transmission to the TC according to the agreed format;
  • Receiving status data from the OBE to ensure correct functioning of the OBE;
  • Receiving value added service data from the OBE when implemented;
  • Transmitting OBE data received and interpreted to the EP back-office for processing;
  • Generating KPI’s and general survey reports on the OBE’s for immediate action in case of failure or lack of performance.

The Proxy is a real time application which needs to be secured, redundant and dimensioned in order to process the large volume of information which is exchanged. The infrastructure needed to run the OBE is complex and requires specific skills in the field of real time processing. A particular attention needs to be given to Proxy software updates, which will be necessary from time to time: the consequence of update failure could break the link with part of the active OBE’s with dramatic financial damages.

4.2 Back-office interface with TC’s

EETS Providers’ back-office interface with TC’s is part of its Back-End which includes also the interface with the Front-End (proprietary) and other EP internal applications such as the customer relation management or the vehicle/OBE database. The EP should pay a particular attention to guaranteeing the unicity of the relation between one vehicle and its OBE and the non-duplication of OBE identifiers.

The EP back-office to back-office interface should use the EN ISO 12855 standard but at this stage, the EN ISO 12855 is only a recommended standard in the framework of the Directive 2004/52/CE. However the standard is only a tool box and its implementation requires to make choices.

During the REETS project, the activity 4 recommends a common REETS profile to be used in the implementation phase. Web service and FTP are basis technologies for the back-office communication. Taking the input from chapter 2 of REETS D4.1 report, three sub profiles have been addressed to CEN in the final Interoperable Application Profile on EN ISO 12855:

  • Profile 1: DSRC based;


  • Profile 2: GNSS/CN based – EP dominant: where the EP is responsible for the whole tolling process from GNSS positioning until the financial management towards its users and the toll chargers;


  • Profile 3: GNSS/CN based – TC dominant: where different allocations of responsibilities are split between EP and TC.


The back-office interface will manage the following exchanges:

  • Trust objects to certify the exchange between the TC and the EP;
  • Toll Context Data sent by the TC to the EP (with a special attention to interconnected toll domain in the DSRC world where the gate of entrance may belong to a different TC than the gate of exit and the transit even made through other toll domains; interconnected toll domains are, in principle, regulated through agreements among concerned TC’s);
  • Exception lists of invalidated OBE’s, sent by the EP to the TC. Exception lists could include temporarily invalidated OBE’s (grey list), permanently blacklisted OBE’s (black list) and white list of valid OBE’s, depending on the bilateral agreement between the EP and the TC;
  • Toll Declarations sent by the EP in profile 2 and 3;
  • Billing details sent by the TC in profile 1 and 3 and by the EP in profile 2;
  • Payment claims sent by the TC;
  • User details and vehicle registration data when requested under the bilateral agreement;
  • Reports on abnormal OBE’s;
  • Exchange of CCC events in profile 2 and 3.

Chapter 4 of the REETS D4.1 report gives detailed information on the Interoperable Application Profile that should be applied. The following table lists the ADU’s as defined in the standard EN ISO 12855:

It should however be noted that at present stage, TC’s back office interfaces are still heterogeneous, the EP’s have therefore to adapt to the requirements of Toll Domains (or Cluster of Toll Domains) and this results in different implementations, high costs and time and need specific testing and suitability for use processes.

The development of profiles of EN ISO 12855 should be progressed in order to reduce the number of variants in the implementation of EN ISO 12855. Furthermore, not only the message transactions and data elements should be covered but also the underlying business processes to reduce the number of possible interpretations of data exchange. Such profiles would:

  1. support the needs of Toll Chargers and EETS Providers;
  2. reduce implementation effort for both Toll Chargers and EETS Providers;
  3. be efficient from the operational costs point of view.

GNSS/CN based systems deserve special attention for their peculiar business model and possible proliferation of diverging solutions for the definition of the tolling schemes. In particular, there are more different allocations of responsibilities between partners involved in business processes than in DSRC based systems. In order to bring forward the implementation of EETS, the harmonization of GNSS/CN tolling scheme types and system requirements should be checked.

4.3 Key performance indicators (KPI’s)

Contractual Key Performance Indicators (KPI’s) are used for improving EETS service quality both on the EP and the TC sides. Implementing similar KPI’s on all EETS Toll Domain give a global overview on the quality of the service provided by the EP on the whole EETS Toll Domain. It gives also elements of comparison between several Toll Domains using the same technologies and may help in the management of the contractual relations between the EP and the TC’s. KPI’s should not be used in a contractual penalty scheme, except if no improvement effort is made by one of the parties.

The REETS project in its activity 3 defines and describes the measurement methods of the KPI in order to ensure the quality of the EETS service between EP and TC and produced, as a result, a toolbox of eleven KPI’s, agreed between TC and potential EP, to reduce the effort and related costs of their implementation.

Six KPI’s apply to both DSRC and GNSS systems (technology-independent KPI’s). One specific KPI has been defined for DSRC systems and five are specific KPI’s for GNSS systems.

The technology-independent KPIs are:

  • EETS Interface service quality : Timeliness
    • Timeliness of provision (from the perspective of the recipient)
    • Timeliness of processing (from the perspective of the sender)
    • EETS Interface service quality : Correctness
    • Payment settlement delay
    • Correctness of OBE personalization data
    • Service user claim response.

The KPI specifically for DSRC considers the OBE Transaction Quality applicable both in multilane free-flow systems and tolling systems with barriers.

The KPI’s included in the Toolbox specifically for GNSS/CN are:

  • Missed recognition events
  • Data provision for detection of charged objects
  • Accuracy of usage parameters
  • False-positive events
  • DSRC Compliance Checking Communication performance.

Measurement methods have been proposed for each KPI in the REETS D3.2 report.

4.4 Acceptance procedure

4.4.1 Registration

The acceptance procedure for an EETS Provider to be able to collect tolls in a specific toll domain starts with its registration in its country of residence and the yearly renewal of its registration. On the technical aspects of the registration procedure, the only requirement is to describe the interoperability constituents the EP intends to use for EETS delivery. There is no obligation at this stage to have implemented the interoperability constituents. However the EP has to certify (in the national language of the Member State of registration) that the interoperability constituents the EP intends to use meet all the requirements set in the Directive 2004/52/EC and the Decision 2009/750/EC.

Certification is defined as an EETS Provider's or its representative's official written statement that its interoperability constituents comply with the associated specified (technical) requirements. The Certification statement needs to be provided to the Member State of registration. The concerned interoperability constituents of the EP are the Front-End and its back-office. The Manufacturer of the Front-End needs to provide a Certificate of Conformity to EETS specifications, potentially with the support of Notified Bodies, and the associated tests results that prove the conformity to specifications. The EP needs to give a description of its back-office and the main processes (data exchange with the Toll Charger, interaction with the driver, vehicle registration data) which are involved in EETS toll collection, and in particular the recovery processes and the time needed to recover in case of major dysfunction of its back-office.

At the yearly renewal stage, there are no specific requirements set in the European regulation however it should be recommended to send to the Member State of registration, a report on the implementation of the Interoperability Constituents and the modifications made or new equipment used since the last registration yearly process.

4.4.2 Technical accreditation in a Toll Domain

Technical accreditation covers the technical aspects of the approval of an already registered EETS Provider in individual toll domains under responsibility of a Toll Charger (or a cluster of Toll Chargers).

In the spirit of REETS, technical accreditation encompasses the conformity to specifications and the suitability for use steps as they are currently applied (or envisaged) in the REETS-TEN countries.

Some toll domains require the proof of conformity to specifications which are valid in respective toll domains. This requires additional tests from the Manufacturers of the Front-End and/or the EP which have to be repeated in each toll domains or cluster of toll domains where such proof of conformity is required. It should be noted that the tests already made by the Manufacturer to establish its own Certification of conformity to specification are not considered sufficient.

Suitability for use concerns the in-service performance of interoperability constituents for end-to-end operations. This process is normally performed by the EETS Providers in cooperation with the Toll Chargers and with respect to the Toll Chargers’ requirements defined for their toll domain(s) (potentially supported by a Notified Body on request of the Toll Charger). It aims at validating the end-to-end processes and performance requirements. Suitability for use processes are generally started after the conformity to specification and the administrative steps (contract negotiation).

There is no harmonization at present time at a European level on the accreditation procedures and no high level certification process of conformity to specification is in place to lower the costs and delays on the EP and the Manufacture side. Most of the TC haven’t yet made an English version of their documents which creates an additional difficulty and a risk of misunderstanding on the EP side. It should also be noted that the full accreditation procedure in each toll domain will take more than one year to be fully achieved. Some TC are envisaging to ask repayment of costs for the accreditation procedure, as part of the bilateral negotiation.

REETS activity 2 has tried to define a common approach on the accreditation procedure in order to improve clarity, effectiveness and fairness and to create conditions which will enable the principle of mutual recognition of proofs of conformity.

REETS activity 2 proposes to split the accreditation procedure as followed:

-         At the registration stage:

  •  Conformity to toll domain independent specifications

-         In each toll domain:

  • Conformity to toll domain specific specifications (if required)
  • Suitability for use

AETIS expressed there cannot be compliance specifications of interoperability constituents which are toll domain specific. Interoperability Constituents used by EETS Providers have to be accepted by all Toll Chargers without the need for changes which might lead to non-compatibility with the equipment which have already been deployed.

A modification of the EU regulation is necessary to oblige Member States to set in place a technical registration process and to ensure the regular control on the evolution of the EP’s interoperability constituents, with the help of notified bodies. The documentation set for conformity to specifications should include toll domain specific specifications in order to ensure general compliance of the interoperability constituent specifications. As a counterpart of the additional burden put on the shoulders of the EP, no additional conformity to specifications procedure should be asked at the TC level: the accreditation procedure would only concentrate on suitability for use end-to-end testing.

4.4.3 Suitability for use

Suitability for use is part of the accreditation process and REETS D2.2 report tried to bring a harmonized method to achieve the suitability for use process.

Stage 1: checking pre-conditions: the EETS Provider is required to submit to the Toll Charger details of which aspects of standards are supported by its interoperability constituents, also submission of test results from laboratory tests or tests conducted at test sites in support of compliance statements.  In this stage, the Toll Charger shall assess whether any specific local requirements are supported.

Stage 2: tests in test environment: checking the general technical compliance of the EETS Providers system with the requirements of the Toll Charger.

Stage 3: end-to-end tests in operational conditions: the correct operation of the EETS Providers interoperability constituents and business processes is confirmed by carrying out trials with equipped vehicles in a test environment (or operational environment) of the Toll Charger under operational conditions and covering all processes end to end.

Stage 4: pilot operation: the Toll Charger is able to monitor the quality of service provided by the EETS Provider using a defined sample of real users. Such pilot would need to define a white list of accepted users within an accepted type of OBE/contract which might not be possible in all European contexts.

Phases 1 and 2 need not necessarily be conducted in each Toll Domain, provided tests are equivalent.  

Phases 3 and 4 are toll-domain-specific and any Toll Charger (or, potentially, cluster of Toll Chargers) may require any applicant EETS Provider to undergo operational trials and pilot operation.

4.4.4 Back-office interfaces

REETS D2.2 report has made an interesting suggestion having in each TC or cluster of TC environment a tests site where EP’s and Manufacturers could check compliance of their back-office interfaces and modifications they intend to set in place. The same should apply to EP’s to allow TC’s to check eventual modifications in their back-offices before putting them in operation.

4.5 Security framework

There is not yet an agreement on a common definition of an EETS Security Policy in the end-to-end process. However the REETS D4.3 report defines some suitable and shared security policy elements and gives an interpretation for a choice of a security policy.

The "high level" part of a security policy covers the security objectives and detailed policy statements which are listed below:

  1. Any EETS toll data exchanged between a TC and an EP shall fall under the EETS security rules;
  2. EETS toll data shall be correct, complete, traceable and protected;
  3. Risk and efficiency should be considered when implementing security in EETS;
  4. The EETS security requirements shall be limited to supporting interoperability between the involved actors.

The REETS D4.3 report, in its chapter 3.6, has defined 21 derived security statements. The Interoperability Management role should be in charge of developing and maintaining a common security policy shared by all EETS actors. The level of EETS information security should not be reduced by the introduction of new EETS actors, services or products. Full traceability of processed information should be guaranteed at all times.

The objective of the information security is to:

  1. ensure confidentiality, integrity and availability of all information in the EFC service operation and management;
  2. prevent and limit the consequences of unwanted or unexpected information security events;
  3. build the required trust and confidence between the involved actors.

Development path for the security documents

Technical audits and compliance check for all new assets, interfaces and processes, based on the Implementation Conformance Statement of CEN ISO TS 19299, should be undertaken and carried out under the supervision of technically competent and authorised personnel.

A common set of security requirements is provided in chapter 5 of the REETS D4.3 report and proposed to become a recommended profile annexed to the CEN ISO TS 19299. Interfaces and data exchanges security mechanisms are described in CEN TS 16439.

The EP needs to pay special attention on its Front End implementation in case the Charge Report has to be authenticated by the Front End and forwarded by the EP unchanged to the TC: this could affect the architecture of the proxy and the application set in the OBE. It is recommended to identify all messages by a unique ID sequential number to prove that no message sent within the Front End has been lost or duplicated and to add a cryptogram to each message generated within the Front End to certify the data integrity. The Front-End should enable a security audit of the internal data exchanges.

5 - Interoperability management

5.1 Interoperability management (IM) role

Interoperability management role represents the regulatory role of the EETS interoperability scheme. However the EU regulation does not prescribe specific IM functions nor does it introduce an organisational body responsible for managing interoperability even though all stakeholders recognizes that such role is absolutely needed.

The article 18 of the Decision 2009/750/EC sets up a coordination group of Notifies Bodies in charge of compiling and maintaining a comprehensive list of standards, technical specifications and normative documents against which EETS interoperability constituents’ conformity to specifications and suitability for use can be assessed. The coordination group of Notified Bodies serves also as a forum for discussing any problems that may arise in relation to the conformity to specifications and suitability for use assessment procedures and for proposing solutions to these problems. But Notified Bodies are supposed to check compliance of interoperability constituents to technical standards and a forum of discussion with Notified Bodies may not be the most efficient way to elaborate a solution in case an EP would face an interoperability issue with a TC or more with a Member State.

In the REETS D5.1 report it has turn out that the scope of IM functions is very heterogeneous, some functions are to be performed on a European level to set the right framework, other functions are rather operational in a direct relationship between Toll Chargers and EETS Providers or between Toll Chargers. A lot of questions related to IM role remain open and would need future works and answers.

The fields of IM functions are the following:

  1. EP registration: how to get homogeneous procedures and conditions in all the Member States to become an EETS Provider and to check yearly compliance for staying an EETS provider in order to establish trust in all the EETS Member States?

  2. Toll Domain Statement: how to ensure a homogeneous quality of the Toll Domain Statements, the free access to the documentation and at least an English version of them?

  3. Technical specifications for the acceptance of an EP in a Toll Domain: how to reduce the specific specifications which some TC want to introduce and how to ensure full compatibility to EETS of such specific specification? How to ensure the availability of at least an English controlled translation of all the technical documentation? How to reduce costs to achieve interoperability in all the EETS Toll Domains?

  4. Contractual framework and accreditation procedure: common understanding of the roles and obligations of both parties and the acceptance of the EP in all Toll Domains. How to make the acceptance of EP’s more cost efficient and easy to set up?

  5. Technical evolution: how to manage technical evolutions, such as, for example, the introduction of a new OBE on the EP side or modifications of the RSE or the central application on the TC side, without penalizing modernity?

  6. Global risk management of EETS and failure of compliance to specifications: how to deal with non-compliance to agreed KPI’s or even failure of an EP with heavy consequences on the whole EETS market? How to increase the coverage of risks at a global European level? Are all the stakeholders able to accept their part of risk and what happens if they fail? What share of risks between EP’s and TC’s seems reasonable? What kind of mitigation measures have to be implemented and at which level: Europe, Member State, TC, or EP?

  7. Introduction of new actors: how ensuring that guidelines followed by the majority of stakeholders will be accepted and understood in the same manner by all EETS actors (especially new coming) and become the rule applied by all EETS actors?

  8. Security policy: how to ensure homogeneous and reasonable requirements for the security policy without needing unaffordable effort to comply with?

  9. Settlement of disputes: the chapter III (articles 10 and 11) of the Decision 2009/750/EC mentions the obligation for Member State to set in place National Conciliation Bodies in order to facilitate and mediate between TC’s and EP’s the resolution of conflicts or the difficulties to finalize their contracts. How will such organism (independent from all EETS stakeholders) be able to get the right knowledge of such a specific world as EETS and how National Bodies can take into account a European wide service with constraints for interoperability which might be the source of the dispute? How long the mediation will take before a solution can be put in place? How will settlement of disputes be monitored at a European level?

Some recommendations have been introduced so far, especially by AETIS:

  1. New EETS actors: guidance should be given to any new tolling scheme subject to EETS with regard to the harmonized aspects already reached (best/common practices), in all areas: contractual, procedural and technical.

  2. Registration: harmonization of the initial and regular evaluation (process and criteria) of registered EETS-Providers to avoid advantages/ disadvantages due to different assessments.

  3. Contractual and financial relations: monitoring the fair and transparent application of the remunerations principles for the various services and functions of EP’s.

  4. Accreditation: Toll Chargers should cooperate between each other to foster the harmonization of accreditation procedures, the development of harmonized test specifications and common test sites. Harmonization of accreditation/ recertification processes and assurances of mutual acceptance of accreditation/ recertification results through learnings across toll domains.  Assessment of changes to interoperability constituents and control of the impact on toll collection.  Generic, cross domain EETS requirements and certification procedures which are accepted in all domains should be agreed. Toll domain specific procedures and tests must be reduced to a minimum.

  5. Testing and implementation: guidance and consultation on the application of standards to refine the standards eventually leading to more harmonization.

  6. General: alignment of conciliation bodies in specific areas which are of general EETS interest.  Alignment to EU and Members States in specific areas which are of general risk to EETS. Further the IM should be elaborating on solutions for managing the global financial risk and its evolution, represented by EETS when it starts alive. This could be one of critical areas of EETS when one EP covering a larger market share is facing a financial crisis or insolvency.

  7. Monitoring: continued harmonization and analysis/comparison (incl. recommendation for quality improvement) of KPI’s for TC and EP across toll domains and monitoring fulfilment of KPI’s.

  8. Customer relations: harmonization and simplification of SU data and vehicle data across toll domains. Harmonization of EETS for the SU.

  9. Communication and information exchange: provide an information platform for EETS to SU, EP, TC and Member States.

5.2 Conciliation bodies

A conciliation procedure has been introduced in chapter III (article 10 and 11) of the Decision 2009/750/EC in view to settle disputes between Toll Chargers and EETS Providers during contract negotiations and in their contractual relationships. National Conciliation Bodies should be consulted by Toll Chargers and EETS Providers in search of a dispute settlement relating to non-discriminatory access to EETS domains.

The Conciliation Bodies are especially empowered to examine whether the contractual conditions imposed by a Toll Charger on different EETS Providers are non-discriminatory and a fair reflection of the costs and risks of the parties to the contract. The national Conciliation Bodies should exchange information about their work, guiding principles and practices.

The main areas where alignment is required are remuneration issues, requirements in the certification process or solutions for managing the global financial risk and its evolution. These elements should be included in the description of the conciliation procedures by each toll scheme alike.

The existing bodies only have a national remit and EETS is not their main or only responsibility or organisational function. This leads to questions such as “How can a national conciliation body determine if requirements for certification are excessive without comparison to other similar certification processes?”

5.3 Potential EETS IM operational governing body

Pan-European IM tasks are currently managed through existing organisations or activities, as already defined by the Directive 2004/52/EC and the Decision 2009/750/EC. This includes, amongst others, the Toll Committee, the Coordination Group of Notified Bodies, Conciliation Bodies, standardisation bodies or the REETS pilot project. It has to be checked again, at a later stage, whether this assignment is sufficient to properly manage the further development of EETS.

The success of an IM task strongly depends on (financial) resources allocated to the IM task. For each IM task and IM organisation sufficient funding needs to be ensured (starting with IM tasks with high importance), if not already ensured. Critical in this aspect could be the funding of the coordination group of Notified Bodies.

In consideration to the IM tasks identified so far, work should be done to establish a new organisation (a new coordinating stakeholder). However, REETS D5.3 report proposes that an “IM Cloud” be considered as a basis for a decentralised governance model. The paradigmatic solution is based on the assumption that existing stakeholders or such that shall be established according to the EC Decision 750/2009 (EETS Decision), will take over the roles in a coordinated IM structure. This follows also the decentralized approach of the EETS Decision.

The REETS D5.3 report has identified the following high level issues of specific relevance:

  1. Consistency/harmonisation of the Registration procedures;

  2. Clear choices about the communication interface standards (EN ISO 12855 and IAP);

  3. Clarification on the certification ambit (role of the Notified Bodies coordination group, mandates to the standardisation bodies…..);

  4. Toll payment cross border enforcement, so far left to the stakeholders or to inter-states bilateral agreements only;

  5. Harmonisation of toll context data;

  6. Effective functioning of the Conciliation Bodies and of the Conciliation Bodies network.

In addition to the above issues, the question of the risk management of EETS remains still not properly identified as a major pan-European issue which fundamentally underlies trust between actors.


                                                                                                  *    *

Starting cross-border interoperability through the REETS project will show how IM issues could be managed at a European level through the IM Cloud principles suggested by the REETS D5.3 report, however it already appears that fundamental issues on risk management have not yet found the right answer to a global pan-European approach.


EETS Provider” (EP) means a legal entity fulfilling the requirements of Article 3 and registered in a Member State where it is established, which grants access to EETS to an EETS User;

Service User” (SU) means a (natural or legal) person who subscribes a contract with an EETS Provider in order to have access to EETS;

Interoperability Constituents” means any elementary component, group of components, subassembly or complete assembly of equipment incorporated or intended to be incorporated into EETS upon which the interoperability of the service depends directly or indirectly, including both tangible objects and intangible objects such as software;

Interoperability Manager” gathers the functionality that deals with overall management of EETS. This includes rules for interoperability, id-schemes, certification, common specifications, etc.

Clusters of TC’s or EP’s means companies having signed an agreement among them to offer common services within EETS;

On-Board Equipment” (OBE) means the complete set of hardware and software components required for providing EETS which is installed on board a vehicle in order to collect, store, process and remotely receive/transmit data;

Road Side Equipment” (RSE) is located along the tolled road and belong to the TC for the purpose of the toll collection. It can be a DSRC antenna, an augmentation beacon or any enforcement tool;

Augmentation Beacons are DSRC road side equipment located in places where GNSS positioning is missing to send a liable position to the OBE through the DSRC link.

Completion Check Communication” (CCC) equipment is used in satellite tolling for enforcement using the DSRC link to check compliance of OBE’s travelling in the neighbourhood of the equipment;

Conformity to Specification” means the ability of an interoperability constituent to comply with EETS specifications;

Toll” means a charge, tax or duty levied in relation with circulating a vehicle in a toll domain;

Toll Charger” (TC) means a public or private organisation which levies tolls for the circulation of vehicles in an EETS domain;

Toll Context Data” means the information defined by the responsible Toll Charger necessary to establish the toll due for circulating a vehicle on a particular toll domain and conclude the toll transaction;

Toll Declaration” means a statement to a Toll Charger that confirms the circulation of a vehicle in a toll domain in a format agreed between the toll service provider and the Toll Charger;

Charging Data” are data transmitted to the Toll Charger to calculate tolls;

Toll Domain” means an area of EU territory, a part of the European road network or a structure such as a tunnel, a bridge or a ferry where toll is collected;

Toll Domain Statement” means the conditions listed in the Annex 1 of the Decision 2009/750/EC, stated by a TC, which regulates the toll collection in its Toll Domain and the acceptance of EP’s;

Toll Transaction” means an action or sequence of actions in which a toll declaration is passed to the Toll Charger;

Toll Charge” is the result of a valid toll declaration after calculation of the toll amount due;

Vehicle Classification Parameters” means the vehicle related information according to which tolls are calculated based on the Toll Context Data;

User registration” is sometimes required by Toll Charger, especially where toll is a tax: the TC needs to register the user and its vehicle information data to notify tolls;

OBE Personalization” consists in introducing the identification data which link to the EP on one side and its customer on the other side and the Vehicle Classification Parameters required for toll;

Manufacturer” means the company who manufactures and provides the On-Board Equipment and the proprietary software which controls the operations of the OBE based on satellite positioning technology. The Manufacturer is responsible for the certification of the Front End he provides to the EETS Provider. Certification means demonstrating compliance of all interoperability constituents of the Front End to European standards and EETS requirements;

Front End” means the combination of the OBE, central hardware and the proprietary software which ensures the control on all the OBE in operation and allowing DSRC as well as satellite tolling methods;

DSRC” meaning Dedicated Short Range Communication, is one the technical communication tools used for EETS, complying with ISO 15509 standard. DSRC uses 5.8 Ghz frequency;

Free flow” is a method of toll collection where toll amounts are determined without stopping vehicles either by DSRC communication or by satellite positioning;

Satellite tolling” is a method of toll collection using vehicle positioning determined by GNSS (satellite positioning network) and GSM data transmission;

Registration” means the procedure to be fulfilled by companies seeking becoming EETS Providers according to the requirements mentioned in the article 3 of the Decision 2009/750/EC:

a) hold EN ISO 9001 certification or equivalent;

b) demonstrate having the technical equipment and the EC declaration or certificate attesting the compliance of the interoperability constituents as laid down in Annex IV(1) of the Decision;

c) demonstrate competence in the provision of electronic tolling services or in relevant domains;

d) have appropriate financial standing;

e) maintain a global risk management plan, which is audited at least every two years;

f) be of good repute;

Accreditation” covers the whole procedure (contractual and technical) to be successfully fulfilled by an EETS Provider in order that its technical system could be accepted on a Toll Domain and that the TC entrusts the EP with the toll collection and the invoicing process to the SU. When the Accreditation is successfully completed, the EETS Provider is “accredited” in the relevant Toll Domain;

Suitability of Use” means the ability of an interoperability constituent to achieve and maintain a specified performance when in service, integrated representatively into EETS in relation with a Toll Charger’s system.

“Exception List” means the list of invalidated on-board equipment established by the EP and related to their EETS contracts with the EETS Users. The EETS Provider shall not be held liable for any further toll incurred through the use of such invalidated on-board equipment when transmitted to the TC.

Reselling Model” describes a business model where a service company is buying services from another service company to resell the service to its customers. In the context of EETS the service consists in toll invoiced from the TC to the EP and re-invoiced to EP’s customers, in its own name but on behalf of the TC to keep the link with the nature of toll (and its VAT rules). Invoicing cycles and terms of payment are defined freely between the TC and the EP on one side and between the EP and its customers on the other side. Service fees have to be invoiced separately from tolls.

Agency Model” describes a business model where a service company “A” gets a mandate from a service company “B” to represent the service company “B” and invoice its services to customers. The invoices are issues in the name of the service company “B” to the customer who is contractually linked with both the service companies “A” and “B”. The contractual conditions between “A” and its customers reflect the requirements of the service company “B” and may not be freely negotiated between “A” and its customers. Service Company “A” has not legal right to claim to court the invoice amount of its customer, in case of non-payment. In the EETS context, such model requires a specific contract between the customer and the EP for each Toll Domain where the Agency Model applies.

Customer Mandate Model describes a business model where the customer of a service company asks this service company to represent himself for the payment of a tax he is liable for, through a formal mandate communicated to the tax-office. In the EETS context, such model would apply where toll is a tax, which by law requires to know the tax-payer to establish the tax statement. The EP cannot be formally invoiced for such tax and must therefore get a formal mandate from the tax-payer to be enabled to receive the tax statement and pay the tax on his behalf. Such model was intended to be in place for the French Ecotaxe.

Enforcement” means equipment and procedures set in place by the toll charger and/or public authorities to detect toll evasion and fraud and to enable collection of tolls and fines from toll evaders.

User registration” applies normally only where toll is a tax and consists in the procedure which a user needs to perform in order to be registered in a toll domain. In general personal data from the user and documents from its vehicles have to be produced. National regulation defines the documents and the procedure for user registration.

KPI” means quality measurement criteria used to qualify the service provided by a service company.

Risk” can be defined as the possibility of a negative occurrence such as damage, injury, liability and loss, which is caused by either an internal or external vulnerability.

Risk Management” is the process of analysing and assessing the exposure to risk and determining how to best manage the exposure to limit or even eliminate the risks. Risk management involves the identification, assessment, and prioritisation of the risks and the application of resources to minimise, monitor and control the probability and/or impact of the negative occurrences. A risk management plan should list all the significant risks which have been identified, their probability of occurrence, the financial consequences and the consequences for the company if the risk occurs, and the mitigation measures which can be/are undertaken. The risks could be classified by level (consequences vs mitigation measures taken) and occurrence. The risk management plan should identify the internal as well as the external significant risks with regard to:

1. Business interruption (failure in the information processing chain …);

2. Cash flow/liquidity risk;

3. Economic slowdown;

4. Increasing competition;

5. Damage to reputation;

6. Failure to reach or maintain full EETS domains coverage;

7. Difficulty to reach required quality-of-service levels;

8. Third party liability;

9. Regulatory/legislative changes;

10. Non-EETS activities.

[1] As an example: an EP may cover the whole EETS Domain by having direct agreements with TC operating a satellite system and use a partnership contract with another service provider covering for instance Spain (where only DSRC-CEN is used) and a second one for the French DSRC network. The EP would introduce three pages of data related to its own identifier, the identifier of the Spanish partner and the identifier of the French partner. In Germany for instance, the EP will be recognized as providing the service, in Spain it will be its Spanish partner and in France its French partner, each of which having bilateral contractual agreements with TC in Spain and in France respectively.

Total Marketing Services LogPay Financial Services GmbH RESSA (Red Espanola de Servicios S.A.) euroShell Deutschland GmbH & Co. KG DKV EURO SERVICE GmbH + Co.KG TRAFINEO GmbH Axxès SAS eurotoll OMV UNION TANK Eckstein GmbH & Co.KG (UTA) Telepass S.p.A. W.A.G. payment solutions, a.s. Multiservice Europe S.E. Easytrip France SAS Via Verde Portugal, Sistemas Electrónicos de Cobrança, S.A.
Privacy policyDisclaimer