Hybrid Solution of Interoperable European Toll Service

The paper summarizes the interoperability bottlenecks of EFC (Electronic Fee Collection) on the level of European electronic toll services and provides proposals for a new hybrid architecture that fulfils all European requirements, is compatible with current standards and enables the use of all admissible technologies for toll data collection (GNSS, GSM/GPRS, DSRC) specified in EC Directives. The hybrid solution is discussed with respect to the future development of Czech electronic toll system and also with respect to the interoperability of our neighboring countries.


HISTORY OF EFC REALIZATION IN THE CZECH REPUBLIC AND LESSONS THAT HAVE BEEN LEARNT
From the beginning 2003 a tender for EFC for trucks above 12 tons had been prepared in the Czech Republic by the Ministry of Transport.The whole process was speeded up due to the increasing of volume of foreign trucks using the Czech Republic as an alternative routing when Austria and Germany started their own EFC systems.The tender, published in 2005, called for the building and operation of an EFC system for about 2000 kilometers of highways and selected 1st class roads.All trucks above 12 ton, with some exceptions for the army, security guards and buses, are obliged to pay.The average price for 1 km was specified by the ministry in the amount of 0.13 cents.
A complicated selection procedure had chosen a microwave DSRC system.The EFC system has been successfully in operation from 1st January 2007 and the first results after one year show that revenues are 50% higher than had been expected.
A contemporary consideration suggests to extend the charging system to 6000 km of the 1-st class roads and to about 2000 km of the 2-nd class roads.The price per kilometer had considered: Regulation of using alterative roads; Economical profitability not only for the state, but also for regions; Restriction of possible increasing of commodity stuff due to charging.
The new supplier of satellite technology GNSS will be accepted by a new tender according to European directive 2004/17/EN and according to legislation of the Czech Republic.The strict requirements will be applied to the supplier -both subsystems (DSRC and GNSS/CN) shall be integrated into one system with priority given to GNSS/CN system.The expert group elaborated this concept in March 2007, and it has been named the Hybrid System.The concept comes from the theory of hybrid systems used in automation.

FAILURE OF EUROPEAN STANDARDIZATION
After a very long way and tens of hours of discussions between the standardization committee CEN/TC278 "Road Transport and Traffic Telematics", it was possible to say that the set of DSRC standards had been finished in 2004.Quite a different situation is in the field of GNSS/CN.
There are two satellite systems in operation as an EFC system in Europe at present.The german system is a proprietary system covered by a set of patents.Document CEN N1934 "EFC standards and IPR" speaks of about one hundred patents.A very similar situation is according to the Swiss system in view of the fact that it has never published its technical specifications.There is only one possibility for countries aiming to introduce a GNSS based system -to rely on a European standard.The GNSS standard is the only possible way to ensure the necessary interoperability in the European countries.
The first, and, up to now, only one realistic proposal of a GNSS/CN standard was elaborated by WG1 of TC278 at the end of nineties.Standard 17 575 "Application interface definition for electronic fee collection (EFC) based on Global Navigation Satellite Systems and Cellular Network (GNSS/CN)" was formed rather sadly coming from two basic reasons: Since there was no common idea how future GNSS/CN were to be built it was decided that the standard should be written as a "toolbox standard"; The existence of cellular networks based on a standard like GSM led to the conclusion, that the communication stack according to the OSI/ISO 7 Layer Model was well covered.
The standard describes the basic concept of GNSS/CN, scenarios of transactions, description of application layer, etc. in 130 pages.During discussion within the CEN community the standard was remitted due to huge criticism.Just suggestions raised fill more than 80 pages.After a number of meetings in the years 2005-2007 it was decided to stop the work on this standard and split it into a few smaller parts: Charging; Communication: transactions and connections to lower layers; On line updating of toll data and software; Roaming.
The expected term of publication of official standards in 2011 evoke thoughts of the same situation, where DSRC was in the nineties.A number of countries designed their charging system following preliminary DSRC standards.The implication of the non existence of valid standard is now solved in a complicated way within the projects as CESARE or RCI, searching for interoperability of different providers of DSRC.
The problem of a non existing GNSS standard is an absolutely crucial problem for the Czech Republic because the tender for charging system for about another 8 000 km roads is under preparation and it will be published shortly.Actually, a worse situation is in the Slovak Republic because the tender for about 2000 kilometers was published at the end of 2007 and they are in a process of evaluation.Hungary also published a tender as a preliminary tender and they are also in the process of starting a charging system.
The worst scenario would be if the Czech Republic would set up its own satellite system, and the same happens in the Slovak Republic and Hungary.The quality and openness of the interface would be only in the hands of the suppliers, and if these would be different, we would have three incompatible EFC systems in this region by 2009.Together with Germany and Switzerland it would make five incompatible systems.To harmonize these systems will cost a great amount of money even if it would be at all possible.
An expert group, having been aware of this situation, proposed to the Ministry of Transport probably the only one possible solution.The solution is to prepare a "de facto" standard describing data exchange only in one cross-section of the complex information chain between On-board-Unit (OBU) and the central system (CS).This proposal, described in the following chapters, comes from ideas from European projects MISTER and RCI, as well as from standard proposal 17 575.

ARCHITECTURE OF EUROPEAN ELECTRONIC TOLL SERVICE
The European electronic toll service (EETS) is described in European Directive 2004/52/EC ("the interoperability directive"), in the following way: "Operators shall make available to interested users on-board equipment which is suitable for use with all electronic toll systems in service in the Member States".At the technical level, the EETS therefore comprises the availability of suitable On-Board Equipment (OBE) which will operate in all European EFC systems.
The Minimum Interoperability Specification for Tolling on European Roads (MISTER*) is currently a document which was produced in 2004 by the contract team working for the Commission on the finalization of the draft standard ISO 17575.This draft standard provides for a set of standardized transactions for communication between on-board and central equipment (CE) in an EFC system based on Global Navigation Satellite Systems (GNSS) and Cellular Network (CN) communication.The MISTER was intended as a first draft of the EETS specification, in particular of the EETS OBE.In 2006, MISTER was amended by the Expert Group 9 † (EG9) to define the minimum functionality of an On-Board-Unit able to perform the vehicle part of the pan-European EFC service.
All documents have been provided to the Road Charging Interoperability project (RCI) which is expected to modify and extend the current draft.The RCI Architecture shows on Fig. 1 the relations between the following actors: EETS User, EETS Provider and the Toll Charger.This architecture agreed in the RCI project allows for both so called "thin client" and "thick client" type of on board units and makes the interfaces between the actors more visible.For the case of interoperability the interfaces and the data exchange through them are of greater importance than the physical units.Some of the interfaces can be regarded as "internal" as they relate to functions belonging to the same actor and are less important for achieving interoperability.The most important interfaces are between the EETS provider (role) and the Toll Charger (role) for exchange of data declaration of road usage and data for enforcement.The RCI architecture shows the technical interfaces that require standardization for achieving interoperability: Interface 1: standardization of vehicle-provided access points for the servicing and maintenance of road charging OBE is not considered critical for interoperability.
Interface 2: standardization of in-vehicle integration of OBE is not considered critical for interoperability.Interface 3: standardization of the Human Machine Interface (HMI) of the OBE is not considered critical for interoperability (functional HMI behavior can be specified through interface 5 as part of the Toll Context Definition).Interface 4: the data exchange for sending the 'use data/charge data from the (toll service provider) TSP to the Toll Charger needs to be standardized.For GNSS-enabled road charging: standardization in progress in CEN.For DSRCroad charging: EN 15509 can be used.Interface 5: Exchange of the specifications that defines the functionality (charged objects, events and actions) of the Toll Chargers' tolled infrastructure (Interface 5 also hosts the back office transactions/clearing between the toll charger (TC) and the toll service provider (TSP) which is outside the scope of RCI  We can summarize our analysis in that the design of current EFC systems is based more on a series of specifications defining the information exchange between the frontend and the central systems in EFC based on a different kind of on-board equipment (OBE).Due to the enormous versions of OBE and over-estimated role of OBE in the whole system the standardization does not lead to the expected goal.On the other hand, specifications analyzed above did not solve, for example, the combination of all technologies DSRC, GNSS/CN but only solved the combination of a thick/thin satellite variant of OBE.Most of these approaches limit the use of OBE in some specific position in the system design.Finally it leads to a system unusually limited by a standard, to some specific OBE design, not leaving a space in the market for new emergent technologies.Also the business architecture had been widely bound by the standards, when only one globally interoperable unit has to be used.
Our approach overcomes all mentioned problems and provides a new system oriented insight on EETS architecture.Firstly, we identify the three main parts of EETS as: EFC data provider, EFC data processor and EFC data user.Based on this categorization, we can approach definitions of interfaces on a more convenient abstract level than was done within analyzed EU projects.This new approach is independent of the data collection method and all suppliers of EFC data collection service can be incorporated into the design of the system.It facilitates an ability to integrate different EFC data suppliers no matter which technology was used for data collection.In chapter 2 we describe the EFC hybrid approach together with its architecture and business model.In chapter 3 we summarize the benefit of the designed architecture for future EFC for the Czech Republic and also for whole of Europe.Chapter 4 concludes the paper.

HYBRID EFC SYSTEM SPECIFICATION
A hybrid system specification could be easily explained on the layered architecture according to Fig. 4. As can be recognized, three basic layers of hybrid EFC system are defined.These layers distinctively clarify three different functionalities of the hybrid EFC system.The functionality of hybrid EFC system could be seen from the point of its role in data processing as follows: Data Provider, the functionality having a major goal in providing trusted data from the data collection environment to the central part of the system for data processing.Data Provider subsystem has to form a trusted system from the point of view of security and in this way provides trusted non-repudiated data to the central system; Data Processor, where all the data are processed by applying at least a minimum set of means necessary for toll collection.The central system can provide all basic toll collection functions based on data provided and it is not expected to broaden this functionality beyond some extent*; Data User, which is a free collection of functionalities of a different kind, using data from a central system for further calculations and applications, mostly user specific oriented; Two cross-sections are important for the hybrid system, specifically the point where these sections are made: Data Provider/Data Processor cross-section, which effectively cuts the information flow between; Data Provider and Data Processor on the side of data provisioning, where trusted data are transferred into the Data Processor and possibly some amount of information is provided to the Data Provider from the Data Processor, e.g.some specific information known to the Data Processor only; Data Provider and Data Processor on the other side of the Data Provider subsystem.This specific cross-section is expected to be used for a unified way of validation of the information obtained from the data Provider subsystem; Data Processor/Data User cut, which is not a part of this specification and has to be standardized as an interface for implementation of user specific functionalities, running behind the Data Processor subsystem, insulated by the Data Processor/Data User interface.These cross-sections above form three distinguished parts of the system and show two important places where standardized interfaces have to be defined.

Hybrid system architecture
A hybrid system architecture standardization goes behind the simple definition of the functionality of OBE.The hybrid system defines the combined functionality of OBE and so called "Context Server", which is a functional unit dedicated to the interpretation of behavior of the whole data collection system, behind it into a standardized context on the interface between Data Provider and Data Processor*.
The OBE, context server and the communication environment of the subsystem forms complex architecture, which could be seen as a "black box" with two interfaces on its border sides.For further explanation it would be useful to study Fig. 5.The green line shows the scope of the definition of interfaces within the hybrid EFC system.Data provider subsystem communicates with Data Processor subsystem via a set of layers defined as follows: Context Server Layer on the edge of the Data Provider Subsystem provides an instrument of communication with the Data Processor Subsystems by means of the standardized language of the interface.The partner in this communication on the side of Data Processor Subsystem is the Access and Arbitration Layer*.Arbitration Layer is the only place where information from any outer subsystem can enter the Data Subsystem and where the information could be accepted or obtained.A major role of the layer is to arbitrate between information obtained from different sources -Context Servers †.Access Layer, is the common input to the Data Processor Subsystem handling all the necessary functionalities belonging to secure access and communication with outer subsystems ‡.Enforcement Interface Layer on both Data Provider Subsystem and Data Processor Subsystem is dedicated to the verification and validation of the selected information from the Data Provider Subsystem via an enforcement specific channel.The Enforcement Interface Layer on the side of the Data Processor Subsystem is handled by its own access and security means.
To define a standard for the hybrid EFC system we have to describe two major interfaces, which are shown in Fig. 5 as Definition "C" and Definition "E", where Definition "C" characterizes the standard interface for the subsystems data exchange.This is done by definition of "languages" on that interface, which has to be common enough to describe the behavior of the interface and data structures transferred.As a part of the standard, the ISO/OSI layers could be defined for that standard interface §.
Definition "E" specifies the information exchange on the enforcement level.There is also the expectation that as a part of the standard, the ISO/OSI layers could be defined for that standard interface.
As can be easily understood, the basic idea of the hybrid system architecture doesn't limit the Data Provider to any of the predestinated technology of capturing data for electronic toll collection.It only describes the edges of the "black box", which easily could be seen as e.g. a proprietary system.Then, on these edges, the standard behavior of the "black box" is expected, defined by the "standard language" (functionality of the "standard interface") and "standard data structures" (information transferred over the standard interface).This approach simplifies the system design, allowing full interoperability; including roaming among systems involved and, as a matter of fact, creates a new business environment with a precise definition of roles and responsibilities.
* As matter of fact, the order of Access Layer and Arbitration Layer is not important from the point of view of functionality of this part of the system.† The Context Server is the functional edge of every Data Provider and it would be expected that there could be more than one Data Provider covering the same area of EFC.Based on this expectation we have to be able distinguish between similar information coming from different sources -Data Provider Systems.‡ It is expected, that the information exchange processes within these layers are based on standard client/server architecture.§ We believe that most of these ISO/OSI layers could be a part of a standard network interface as e.g. a TCP/IP stack.Only some top layers, as, for example, the application layer, would be different.

Business specification
According to architecture described above, we should understand "the Toll Charger" as a recipient of the road usage charges, the abstract actor associated with the Toll Charging role.On other hand, we should also understand "the Service Provider" to be an abstract person responsible for operating the data collection environment and in such a way providing trustworthy data to the Tool Charger.The relation between hybrid system architecture and business model can be described in Fig. 6.As can be seen, the business specification and the hybrid system architecture correlate and give an opportunity to define a clear and simple business relationship among entities involved.Clear definition of roles and responsibilities introduces a comfortable environment for the setting up of non overlapping Service Level Agreement contracts based on a well defined architectural model.

The consequences of hybrid EFC architecture
The original idea of layers elaborated by PT20 is shown in Fig. 2. The new scheme proposed by this solution is very close to the scheme as it is shown in Fig. 7.The main difference is that all suppliers of OBU´s have to also deliver Context Server -Proxy.Connection to the central system will be "symmetrical" for all suppliers and the Proxy server will transfer date on the same way.

CONCLUSION
The Hybrid System Architecture for the Electronic Fee Collection System introduces a new view on the standardization process, based on the clear definition of roles and responsibilities inside the system.Also it establishes a new system cross-sectioning, where the original highly important role of the OBE is suppressed and a new role of the Data Provider is introduced.This approach leads to the simplification of the interoperability problem, establishing of a new competitive market for the OBE and Data Provider Services.Also, well bounded model creates a cleaner legal environment for the definition of individual services and the preparation of the SLA's.

ACKNOWLEDGEMENT:
The presented results were derived from the work of Electronic toll expert group of the Minister of Transport, Mr. Ales Rebicek, who established and financially supports the expert group activities.

Figure 2 :Figure 3 :
Figure 2: Gradual transition between thin and thick architecture extremesand the interface in cope of this Technical Specification of PT20

Figure 5 :
Figure 5: Structure of interfaces in hybrid solution

Figure 6 :
Figure 6: The relationship between models of the business specification and the hybrid system architecture

Figure 7 :
Figure 7: The new scheme is symmetrical for all suppliers OBU´s

The RCI Architecture of EETS with 5 interfaces between EETS provider and Service User/Toll charger roles
* Project supported by EC † Expert group established by EC Project supported by EC: www.ertico.com/rciFigure1: ).For GNSS-enabled road charging: standardisation in progress in CEN.RCI validated the concept of the Toll Context Data and RCI will finalize a report that shows how LSVA and Toll Collect can be translated in this RCI Toll Context Data.For DSRC-road charging: no other use than for back office transactions/clearing between the TC and the TSP which is outside the scope of RCI.Interface 6: Enforcement interface must allow each Toll Charger to easily check the compliance of the Front End of all TSP sactive on his tolled infrastructure.For GNSS-enabled road charging: standardisation in progress in CEN.For DSRCroad charging: EN 15509 can be used In 2008 the new approach into CEN 278 and ISO 204 standardization was announced and new project teams (PT) were created and supported by EC.Working groups CEN278/WG and ISO204/WG play only the role of evaluators and reviewers of work done by PT groups.PT20 starts to divide the draft standard CEN ISO 17 575 into four parts: charging, communication, data elements and definitions of operating more than one EFC regime at the same time.The main principle of PT20 approach is on Fig.2where the main process layers described on Fig.3are differently allocated within Proxy or OBE based on intelligence distribution on OBE.