REETS-TEN Activity 4: Back Office Interfaces
D 4.1 Definition of Back Office Interfaces and of preliminary tests
1 6 . 0 7 . 2 0 1 4 V 2 .0
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 1 of 105
Document revision history:
Date Version Description Document Status Responsible 17 10 2013 0.1 Draft structure and contents of D4.1 Draft Aiscat Servizi 21 10 2013 0.2 Updated draft structure of D4.1 Draft Aiscat Servizi 23 10 2013 0.3 Updated draft structure of D4.1 Draft Aiscat Servizi 24 10 2013 0.4 Updated draft structure of D4.1 Draft Aiscat Servizi 05 03 2014 0.5 Merge with working documents: Business Draft Aiscat Servizi Processes analysis and Detailed Analysis 05 03 2014 0.5a Final merge with working documents Draft Aiscat Servizi 05 03 2014 0.5b Corrections in merge Draft Aiscat Servizi 04 04 2014 0.6 Streamlining document, integrating Draft RappTrans DE systems operational status of participants, review comments of participants, findings/conclusions section, executive summary 04 04 2014 0.7 Integrations and editorial corrections Draft Aiscat Servizi 11.04.2014 1.0 Integrations and editorial corrections Final pre-draft Aiscat Servizi 24 04.2014 1.1 Integration of final comments Final pre-draft Aiscat Servizi 25 04.2014 1.2 Final integrations and editorial correction Final draft Aiscat Servizi 06.05.2014 1.3 Editorial corrections Final draft Aiscat Servizi 08.05.2014 1.4 Integration with comments from ASFA, A, Final draft Aiscat Servizi common glossary and further editorial corrections 12.05.2014 1.5 Editorial correction after WP4 meeting #5 Final draft Aiscat Servizi, in Vienna RappTrans DE 13.05.2014 1.6 Final editorial corrections Final Aiscat Serrvizi 20.05.2014 1.7 Formatting adjustments, correction of Final Lecit references Consulting 03.06.2014 2.0 Final revision Final Aiscat Servizi 11.06.2014 2.0Final Final revision after editorial comments Final Aiscat Servizi 16.07.2014 2.0Closed Include final contributions and approval Final Paolo Giorgi of the REETS Steering Committee
The sole responsibility of this publication lies with the author. The European Union is not responsible for any use that may be made of the information contained therein.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 2 of 105
Content 0 Executive summary ...... 7 1 Introduction ...... 9 1.1 Document objectives ...... 10 1.2 Methodology ...... 10 1.3 Participating Toll Chargers...... 10 2 Profiles ...... 11 2.1 Toll Charger DSRC based (profile P1) ...... 11 2.2 Toll Charger GNSS/CN based (profile P2 and P3) ...... 12 3 EN ISO 12855 functional compliance ...... 15 3.1 Technical support processes ...... 15 3.1.1 Request Message ...... 15 3.1.2 Status Message ...... 15 3.1.3 Acknowledge Message ...... 15 3.1.4 Extended Acknowledgement Message ...... 15 3.2 Business Processes ...... 15 3.2.1 Provide and retrieve Toll Context Data ...... 15 3.2.2 Setting up of mutually accepted EFC Context Marks (CCC, LAC and ETC) ...... 16 3.2.3 Report Toll Declaration...... 16 3.2.4 Report Billing Details ...... 16 3.2.5 Claim Payment (Payment Claim / Payment announcement) for service usage .... 16 3.2.6 Manage Exception Lists ...... 16 3.2.7 Exchange Trust Objects ...... 16 3.2.8 Exchange enforcement data...... 17 3.2.9 Reporting CCC Events ...... 17 3.2.10 Request and transmit contract, vehicle, user details ...... 17 3.2.11 ReportAbnormal OBU ...... 17 3.2.12 Exchange KPIs ...... 17 3.3 Summary of business process analysis ...... 17 4 Business process detailed analysis ...... 19 4.1 Detailed analysis approach ...... 19 4.2 Analysis of ADUs and parameters ...... 20 4.2.1 Toll Context Data ...... 20 4.2.2 Accepted EFC Context Marks ...... 22 4.2.3 Billing Details ...... 23 4.2.4 Payment Claim ...... 27 4.2.5 Payment announcements ...... 30 4.2.6 Toll Declaration ...... 33 4.2.7 Exception list ...... 37 4.2.8 Trust Objects ...... 41 4.2.9 Report Abnormal OBE...... 46
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 3 of 105
4.2.10 Request and transmit contract/vehicle/user details ...... 48 4.3 ADU transport protocol ...... 52 4.3.1 General ...... 52 4.3.2 Process specific ...... 52 5 General results and findings ...... 54 5.1 General results ...... 54 5.2 Results of business process analysis ...... 55 5.3 Findings regarding applied test procedures for back office interfaces ...... 56 5.4 Recommendation to CEN for IAP ...... 58 5.5 Requirements for SPs ...... 58 6 Conclusions ...... 59 7 Annexes ...... 61 7.1 Article 3, 5, 6 of EETS Decision ...... 61 7.2 Application Guide ...... 61 7.3 Business processes tables ...... 63 7.3.1 Transmit Toll Context Data ...... 64 7.3.2 Transmit EFC Context Mark ...... 69 7.3.3 Transmit accepted EFC Context Marks ...... 70 7.3.4 Transmit Billing Details ...... 72 7.3.5 Transmit Payment Claim / Payment announcement ...... 78 7.3.6 Transmit Toll Declaration ...... 82 7.3.7 Transmit Exception Lists (blacklists and/or whitelists) ...... 84 7.3.8 Exchange Trust Objects ...... 89 7.3.9 Report Abnormal OBU ...... 91 7.3.10 Request and transmit contract/vehicle/user details ...... 94 7.3.11 Transmission of missing and / or erroneous records (additional business process in DE)...... 96 7.3.12 Requesting technical OBU information (additional business process in DE) ...... 96 7.3.13 Report DSRC Data records (additional business process in DE) ...... 97 7.4 Example of form for compliance tests ...... 99 7.4.1 Organization of back office tests ...... 99 7.4.2 Interconnected toll domains ...... 100 7.5 Terms and definitions ...... 100 7.6 Other Abbreviations ...... 101 7.7 Glossary...... 102
Index of Figures
Figure 1: List of processes in Profile P1 ...... 12 Figure 2: SP-dominant GNSS-systems (profile P2) ...... 13 Figure 3: Example of a TC-dominant GNSS-systems (profile P3) ...... 14 Figure 4: Sub-interfaces as in the Application Guide ...... 62
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 4 of 105
Index of Tables
Table 1: participating Toll Chargers and toll domains ...... 11 Table 2: Use of business processes in the toll domains ...... 19 Table 3: Toll Context data table ...... 21 Table 4. Context data exchange attributes ...... 21 Table 5. Context data exchange test procedures ...... 22 Table 6: Billing Details table ...... 24 Table 7. Billing Details attributes ...... 25 Table 8. Billing details test procedures ...... 26 Table 9: Payment Claim table ...... 28 Table 10. Payment Claim attributes...... 29 Table 11- Payment Claim test procedures...... 30 Table 12: Payment announcement table ...... 31 Table 13. Payment Announcement attributes ...... 32 Table 14. Payment Announcement test procedures ...... 33 Table 15: Toll declaration table ...... 34 Table 16. Toll Declaration attributes ...... 35 Table 17. Charge report attributes ...... 35 Table 18. Usage statement attribute fields ...... 36 Table 19. Toll declaration test procedures ...... 37 Table 20: Exception list table...... 39 Table 21. Exception list attributes ...... 40 Table 22. Exception list test procedures ...... 41 Table 23: Trust objects table ...... 43 Table 24. Trust objects attributes ...... 43 Table 25. Trust object purpose attribute fields ...... 44 Table 26. Trust object test procedures ...... 45 Table 27: Report abnormal OBE table ...... 46 Table 28. Report abnormal OBE attributes ...... 47 Table 29. Report abnormal OBE test procedures ...... 48 Table 30: Request and transmit user details ...... 48 Table 31. Retrieve User Details attributes ...... 50 Table 32. Provide User Details attributes ...... 51 Table 33. Retrieve Userid List attributes ...... 51 Table 34. Retrieve User List test procedures ...... 52 Table 35: ADU transport protocol ...... 52 Table 36. Internet connected interfaces ...... 53 Table 37: Different use of exception list business process ...... 56 Table 38: Distribution of stages for the three toll chargers who provided input...... 57 Table 39: possible subdivision of level of risk in different toll domains ...... 58 Table 40: List of ADUs as defined in the standard EN ISO 12855 ...... 63 Table 41. Transmit Toll Context Data ...... 69 Table 42. Transmit EFC Context Mark ...... 70 Table 43. Transmit accepted EFC Context Mark ...... 71
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 5 of 105
Table 44. Transmit Billing Details ...... 78 Table 45. Transmit Payment Claim / Announcement ...... 82 Table 46. Transmit exception lists ...... 88 Table 47. Transmit Trust Objects ...... 91 Table 48. Report Abnormal OBU ...... 93 Table 49. Request and transmit contract/vehicle/user details ...... 95 Table 50. Transmission of missing records ...... 96 Table 51. Requesting technical OBU information ...... 97 Table 52. Report DSRC Data records ...... 98
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 6 of 105
0 Executive summary This document D4.1 is the first deliverable of work package 4 of the REETS (Regional European Electronic Toll Service) project. It analyses back office interfaces between toll service provision and toll charging and the respective information exchanges. The aims of this document were to enable harmonization of the interface contents and processes in order to support the realization of the EETS and to create a concept for a possible common interface test system which can be used, for the first phase generally known as Conformity to specifications, before starting the subsequent phase also known as Suitability for Use tests. The clear distinction between these phases is made within the WP1 and WP2. In the second phase the interaction between a SP and a TC is crucial to demonstrate the conformity of the real operation of the EFC system in the TC’s Toll Domain with the SP’s OBU. Nonetheless is it also important to underline that, once a security policy has been adopted by the parties, this may have a further impact on the conformity test phase because the syntax, the semantics, and the logic of the data exchange will have to be demonstrated also taking into account the related security framework. It is worth to underline that the technical topics related to certification are among the WP2 objectives and an according liaison between WP4 and WP2 has been done. To achieve the WP4 objectives, the provisions of the standard EN ISO 12855 have been taken as the basis for assessing the current state of the ongoing and/or planned implementation of back office interfaces within the toll contexts of the participating TCs. Those have been from Austria, Denmark, France, Germany, Italy, Poland, Spain and Switzerland. In order to possibly describe with a good level of details the state of the art, the assessment has been done both on a high level and on a detailed level, for all participating toll domains. In the high level analysis the implementation of the information exchanges (including generic information in the respective toll domains) have been assessed. In the detailed analysis more specific information (e.g. used ADUs, attributes, and current or planned test procedures) have been described in order to facilitate possible paths of harmonization. The following main results and conclusions have been found:
1. Beyond the scope and use of the information exchanges defined in EN ISO 12855, additional information exchanges are required and foreseen by several toll chargers 2. Although all participating Toll Chargers have been oriented in implementing their back office interfaces in line with the provisions of EN ISO 12855, the communication over the several TCs defined back office interfaces is still heterogeneous. At the current state of art, the SPs have had to adapt to the requirements of Toll Domains (or Cluster of Toll Domains) and this resulted in different implementations, but functional consistency exists between the back office interfaces put in place by the participating Toll Chargers and Toll Service Providers. 3. EN ISO 12855 is a toolbox that can be used as a functional framework for the actors for consistency in the development of interfaces and back office platforms. The business processes described in this deliverable, some of which are functionally defined in EN ISO 12855, should be the reference for future implementation, at least within the borders of the pilot project (REETS). This approach should pave the way when enlarging the playground to the entire EU for the future development of the EETS. 4. A given technical implementation of back offices interface is specified according to bilateral contract between the Toll Charger and the Service Provider. Web service and FTP are basis technologies for back office communication applied by the most participants for the information exchange.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 7 of 105
5. Due to the individual EFC system definitions and requirements, the implementation for REETS and EETS may be complex for Service Providers. However, thanks to a cluster approach (like EasyGo, TIS PL, VIA-T, Telepass), unique specifications have been implemented for several decades of Toll Chargers and several SP. GNSS/CN based systems deserve special attention for their peculiar business model and its 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 REETS and EETS, the possibility of harmonization of GNSS/CN tolling scheme types (with special regards of upcoming schemes) and system requirements should be checked. 6. The Interoperable Application Profile (IAP) for EN ISO 12855 per type of Toll Context (DSRC context, GNSS Context) would contribute to facilitate this step for the future development of the EETS to the entire EU. Moreover it should limit the options of the base standard to be used in an interoperable EFC cluster based on the similarities of existing and planned EETS back office interfaces of the EFC systems as shown in this document. 7. The development of profiles in the IAP 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 transaction sequences and data elements should be covered but also profiles covering the underlying business processes to reduce the number of possible interpretations of data exchange. 8. In addition to the IAP, at this stage an IAP test standard limited to the test focus "syntax/format" is also recommended. In fact such a test standard could be applied by each actor (i.e. TC and SP) in a preliminary test phase prior to a first integration test. In the Annexes section (paragraph 7.4) a general description of a hierarchical test procedure is described. 9. Interconnected toll domains might deserve further attention in the Suitability for Use test phase due to the peculiarity of the data exchange model. In the Annexes section (paragraph 7.4) a short account on the topics is given.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 8 of 105
1 Introduction The REETS (Regional European Electronic Toll Service) project, co-financed by the EC via the TEN- T funding, aims at deploying EETS compliant services in a cross-border regional project. The project is supported by Austria, Denmark, France, Germany, Italy, Poland, Spain and Switzerland. One of the technical tasks in the analysis phase of the REETS is developed in order to possibly submit inputs to the standardization bodies to help the deployment of EETS in the member states (MS) , starting from the current state-of-the-art. It is important to clarify the following: a) the term Toll Charger (TC) is referred to a legal entity charging toll for the use of its infrastructure by a vehicle within its toll domain. b) The Electronic Toll Service on the TC’s toll domain is provided by a Service Provider (SP). In the frame of the REETS project and in particular in this document, the acronym used to indicate the provider of electronic toll collection service is SP. EETSP (or EP) is used, when referred explicitly to a SP registered at European level in an EU member state usually, but not necessarily, corresponding to the SPs country of incorporation. The SP for example could be using the registration of its parent company which could be registered in another member state. As an additional explanation, the following are possible stages for a SP before becoming a EETSP: i. Service Provider (SP) is an entity providing a general Service to its customers (including any kind of toll collection service); ii. Toll Service Provider (TSP) is a an entity providing any kind of Toll Service to its customers, on one or more toll domains for one or more classes of vehicles; iii. Electronic Toll Service Provider (ETSP) is an entity providing Electronic Toll Service (by means of an OBU) to its customers, on one or more toll domains for one or more classes of vehicles. The term is dealing with services offered in a limited area of operation (e.g. national, cross border,…) or in Toll Domains of several countries in Europe (for instance EasyGo, TIS- PL, Ecotaxe, Via-T, Via Verde, Telepass and Liefkenshook) . iv. European Electronic Toll Service Provider (EETSP or also EP for brevity) is a legal entity registered in the country where it is established, and recognized at European level providing the EETS (European Electronic Toll Service) to its customers, as stated in the acts defined by the Directive 2004/52/EC, Decision 2009/750/EC and Application Guide published in 2011. The REETS’ WP4 deals with back office interfaces used for the data exchange between Toll Chargers and future EETS Providers. Interface characteristics are certainly determined by schemes already used for years in a given tolling system, as they are also specific for DSRC or GNSS-based systems. Currently, a recently developed common basis for back office interfaces does exist (international standard EN ISO 12855:2012). Toll Chargers have been operating their own proprietary back office interfaces that were implemented prior to the standard, in order to exchange the relevant toll data with the different payment service providers in their tolling systems. Toll Chargers may proceed to extensions that can be seen as extensions to the standard. As the operational needs of both the European TCs and EPs may go beyond what currently dealt with in national systems, additional data elements may need to be exchanged, requiring a change to the currently implemented proprietary interfaces. Therefore, this analysis is made having in mind the standard EN ISO 12855 (which is recommended in the application guide to the Decision 2009/750/EC) in its latest release. The use of standardised interfaces for the data exchange between a Toll Charger and an EETS Provider can obviously reduce the costs for the implementation and ease the deployment of EETS. The development of preliminary test systems may also prevent problems arising in the final step (suitability for use) tests.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 9 of 105
1.1 Document objectives The document shall help understand the current status of data exchange processes between Electronic Toll Service Providers and Toll Chargers in the different Toll Domains with respect to the back-office interfaces. Furthermore it shall give possible indications on how to converge on what existing standards (e.g. EN ISO 12855) suggest on the topic. In particular the document aims at the following objectives: Give a general description of business processes in the EETS context with connection to back- office interfaces for the participating toll domains; Conduct state of the art assessment about the implementation of the EN ISO 12855 standard in the participating countries; Compare back-office interface implementation and possible foreseen tests between TC and SP in order to find similarities and differences Derive findings and conclusions and possibly give further recommendations to CEN for formal standardization
1.2 Methodology To reach the aims described above a two level approach has been used to get the required information: 1. In the high level analysis, an assessment among the participating countries has been conducted in order to better describe their used approach for the data exchange with SPs. In particular, referring to the Business Processes defined in the standard EN ISO 12855, each response had to contain which Business Processes are used, which communication channel is applied and if there was compliance with the requirements specified for that Process in the EN ISO 12855 standard; 2. In the detailed level analysis, a second assessment among the participating countries has been conducted in order to get detailed information about the back-office interfaces data elements and the possible foreseen test stages for the applied business processes. The input received has been discussed among the participants during the WP4 meetings and it has then been used to derive findings and conclusions.
1.3 Participating Toll Chargers The following table specifies for each Member State involved in the REETS project the Toll Chargers or name of Service offered and the status of the system’s operation respectively the status of the EETS implementation.
Description of Service offered in Operational and EETS MS Network and Toll Chargers the network implementation status
CH Federal Customs Administration (FCA) LSVA specific OBU In operation for the mileage-related heavy vehicle charge (LSVA) EETS implementation: ongoing
DE Federal Office for Goods Transport German Truck Toll system / In operation LKW-Maut Deutschland EETS implementation: ongoing
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 10 of 105
Description of Service offered in Operational and EETS MS Network and Toll Chargers the network implementation status
F F1 - ASFA Road Network - 18 Toll TIS PL for HGV- 5 accreditated In operation Domains (some are interconnected), ETS Providers (Axxès, DKV; with common technical and operational Eurotoll, Telepass, Total / EETS implementation: ongoing ETC procedures coordinated by the AS24); these ETS Providers are “Commission de Télépéage” led by also accreditated for other Toll ASFA. domains in Europe.
The organization of the ASFA Road Network, with the accreditated SP, is fully conform to the ETS European scheme as defined by the Directive and the Decision.
F2 - MEDDE – Ministry of Ecology, Ecotaxe road network ECOTAXE for HGV. In standby. Sustainable Development and Energy. EETS implementation: ongoing
I Italian network: 23 interconnected Toll SIT-MP (Italian Interoperable Ready for operation Domains, with common technical ETC Service for HGV) standards and operational procedures EETS implementation: ongoing shared among Toll Chargers.
PL GDDKiA – General Directorate for viaTOLL In operation National Roads and Motorways EETS implementation: ongoing
E Spanish toll network: 34 Via-T ETC system for light and In operation concessionaires with common technical heavy vehicles. Around 60 and operational ETC procedures financial Service Providers and EETS implementation: ongoing coordinated by the ETC Monitoring 7 non financial Service providers Committee led by ASETA
A/DK Asfinag+Sund & Baelt (plus Sweden Toll Service Provider (SP): In operation and Norway) BroBizz A/S (Denmark) and ASFINAG ETS (Austria) EETS implementation: ongoing Table 1: participating Toll Chargers and toll domains
2 Profiles In this chapter the two main toll systems profiles, DSRC and GNSS-CN, are described. This should give a general overview and an introduction for the upcoming chapters. 2.1 Toll Charger DSRC based (profile P1) DSRC based systems started at the beginning of the 90s and are so far the most commonly deployed in Europe. In DSRC based tolling systems the TC is responsible for: The distribution of information regarding the tolled network; The distribution of the tariff table which tolls are based upon; The management of the financial process from the moment of the detection of OBUs in the tolling points to the Payment Claim to the Service Provider.
The Electronic Toll Service Provider is responsible for:
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 11 of 105
The relationship with its customer, final user of toll domains, regulated by a contract; The distribution of OBUs for the vehicle(s) of its customer The distribution of the exception list to the TC; The invoice to the customer and customer billing; The recovery of the toll amount due by the customer for its vehicles The payment of the toll due to the Toll Charger. The following Figure 1 describes the general communication flows between the SP and TC for each process. Each process is initiated either by the SP or the TC. Previously agreed MoU
Trust Objects
EFC Context Data
Excep on lists
Billing Details
Payment Claims
Retrieve User Detail
Provide User Detail
Report Abnormal OBE
Figure 1: List of processes in Profile P1 2.2 Toll Charger GNSS/CN based (profile P2 and P3) GNSS/CN based tolling systems can be differentiated in two major groups with respect to the distribution of responsibility for the tolling process between the SP and the TC.
TSP-dominant GNSS-systems (profile P2) There are systems in which the Electronic Toll Service Provider is responsible for the whole tolling process from GNSS positioning until the financial management towards its users and the toll chargers. The process steps of toll event detection and pre-billing are under the responsibility of the SP. Toll Chargers are only responsible for providing correct toll context data, for monitoring and supervising the Electronic Toll Service Provider and for the enforcement of road users. Those systems are GNSS/CN systems with dominant SP and their specific circumstances are reflected in profile 2 of the EN ISO 12855 standard. The German toll system is one example for a GNSS/CN based system with SP dominant characteristics. The following Figure 2 shows the exemplified tolling process and the respective information exchanges between SP and TC in SP dominant schemes.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 12 of 105
Figure 2: SP-dominant GNSS-systems (profile P2) TC-dominant GNSS-systems (profile P3) TC-dominant GNSS-systems have a different allocation of responsibilities between SP and TC. The difference is basically that the Toll Charger is responsible in some cases also for the process step of toll event detection, but in other cases only for tariffing. In case the TC is responsible for toll event detection the SP is transmitting toll declarations which only contain streams of GNSS-positions to the Toll Charger who decides and identifies the tolled road segments the user has driven on and calculates the toll amount based on the tariff model. In other cases the SP is sending toll declarations to the TC containing the toll events, driven distance, etc. of a user and the TC then calculates the toll amount based on these toll declarations applying the respective tariff model. Those systems are GNSS/CN systems with dominant Toll Charger and their specific circumstances are reflected in profile 3 of the EN ISO 12855 standard. The upcoming French toll system for the national roads is one example for a GNSS/CN based system with TC dominant characteristics. The following Figure 3 shows the exemplified tolling process and the respective information exchanges between SP and TC in TC dominant schemes for the case when a TC is responsible for toll event detection.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 13 of 105
Figure 3: Example of a TC-dominant GNSS-systems (profile P3) Regardless of the specific characteristics with respect to dominant TC and dominant SP, there are processes that are the same in both systems. These are: - Exchanging of Trust Objects for back office communication and for the communication between the SP’s OBE with the TC’s roadside equipment - Transferring of exception lists from SP to TC in order to inform the TC about blacklisted users (blacklist) or about all registered users which are relevant for this TC (whitelist) - Transferring toll declarations from SP to TC in order to inform the TC about the usage of the tolled network by a specific user (remark: Toll Declaration might also be sent after specific request by the TC). Toll declarations might differ in its content between profile 2 and 3. The following are non exhaustive typical examples of toll declaration forms: i) Toll declarations contain streams of GNSS positions (low preprocessing at SP’s side) ii) Toll declarations contain single detected charge objects, e.g. tolled segments (medium preprocessing at SP’s side) iii) Toll declarations contain single detected charge objects including the respective toll amount for the specific vehicle and circumstances (most preprocessing at SP’s side) - Exchanging User/vehicle Details or User Lists for enforcement purposes, where the SP transfers the information after request by the TC - Transferring CCC-Events from TC to the SP after request by the SP - The exchange of quality assurance parameters in both directions between the SP and the TC - Reporting abnormal OBU from TC to the SP The following processes are applicable in profile 2 (SP dominant): - Transferring of Billing Details from SP to TC - Transferring of Payment Announcements from SP to TC The following processes are applicable in profile 3 (TC dominant): - Transferring of Billing Details from TC to SP - Transferring of Payment Claims from TC to SP
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 14 of 105
3 EN ISO 12855 functional compliance In this section both technical support processes and Business Processes are described. In the annex section, a breakdown table, containing the list of Application Data Units as defined in the EN ISO 12855 is placed, with reference to profiles involved (see chapter 7.3). The following definitions of information exchanges are a summary of what is contained in the standard EN ISO 12855. 3.1 Technical support processes 3.1.1 Request Message The Request message may be used to: Alert the counterpart that one is ready to accept any kind of information exchange. Inform the counterpart that one is ready to accept a specific type of message. Request the counterpart to re-issue a specific message. Request for information identified by the type and message content. 3.1.2 Status Message The Status message is used to provide the counterpart general status information on the interface or inform about status on previously transferred information. It may be used to: Provide general information on the status of the interface. Alert the counterpart that some previously provided information becomes invalid. Alert the counterpart that the previous information contained an error and has to be recalled. 3.1.3 Acknowledge Message The Acknowledge message is a generic mechanism (i.e. not related to any specific functionality) that allows acknowledging a specific interaction. This mechanism is provided by the “Acknowledge” message. 3.1.4 Extended Acknowledgement Message The “ExtendedAcknowledge” message is used whenever a specific message in an information exchange needs to be confirmed. The “ExtendedAcknowledge” message indicates the specific message to be acknowledged by specifying its identifier. It may additionally carry an indication of a positive or negative acknowledgment. In addition to the Acknowledge message it provides more sophisticated means to describe the actual problems in processing messages or specific parts of it.
3.2 Business Processes Processes listed in this section are driven by the CESARE (III and IV) model. As it has been noted, that CESARE (III and IV) is not up to date and to be more in line with EN ISO 12855, the names of the processes have been changed. In addition, some already detected missing processes (e.g. Mutual acceptance by SP and Toll Chargers of combination(s) EFC Context Mark // ManufacturerId // EquipmentClass) have been added. 3.2.1 Provide and retrieve Toll Context Data In the EN ISO 12855 the EFC Context Data corresponds to the necessary toll rules (e.g. tariff, map data, enforcement rules, road network characteristics, specific commercial conditions, etc.) that the SP may require for compliant operation (generating of compliant toll declarations in case of GNSS tolling) of all back office processes.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 15 of 105
3.2.2 Setting up of mutually accepted EFC Context Marks (CCC, LAC and ETC) The SP is in charge to: - define its relevant EFC Context Mark(s), - describe the parameterization(s), the personalization(s) and the security mechanisms - for each EFC Context Mark, define on which OBU model (ManufacturerId / EquipmentClass), it will be implemented. The Toll Charger is in charge to implement, in its own central system and in its Road Side Equipment, the processes to accept the personalized OBUs and to manage exchanges between central systems. This exchange is currently missing in EN ISO 12855 and needs to be supplemented. Each bilateral process is based on specific accreditation procedure. The OBUs used by the Electronic Toll Service Providers have to conform to the requirements of the Toll Chargers in the frame of a process between the OBU Manufacturers and the Toll Chargers for a specific Toll domain. 3.2.3 Report Toll Declaration This Business Process is described based upon the toll context: 1. in the DSRC context : the Toll Charger receives “Toll Declarations” from its Road Side Equipment using the DSRC link with OBE (no back office communication between SP and Toll Charger). 2. in the GNSS context : the Toll Charger receives “Toll Declarations” from the ETS Provider according to specifications delivered by the Toll Charger. 3.2.4 Report Billing Details A single Billing detail may refer to one or several Toll declarations. The generation of Billing details by the Toll Charger to SP is based on the requirements defined by the Toll Charger for the toll domain as specified in the Toll Context Data. In GNSS-context, the Billing details may be: - generated by the TC based on the received Toll Declarations - or generated by the SP and transmitted to the TC if mandated by the TC. 3.2.5 Claim Payment (Payment Claim / Payment announcement) for service usage According to the Toll Context Data and used system, the Toll Charger can either: - request a payment from the SP, based on the Billing Details - receive from the SP an announcement about the upcoming transfer of payments, based on the Billing Details. In both cases, the actual financial process is outside the scope of this back office data exchange. 3.2.6 Manage Exception Lists The process corresponds to the exchange of all kind of exception lists (black-list, grey-list, white-list, commercial conditions, etc). The information exchange contains values to identify a user, contract, OBE and/or vehicle, for example by the PAN (or group of PAN, ManufacturerID//OBE-ID, Licence Plate Number // Country, …. Some additional data may be included, depending on the Toll Context and type of list. 3.2.7 Exchange Trust Objects This process shall describe the exchange of all kind of trust objects (keys, certificates, etc.) to be shared between TC and SP either for back office communication or OBE and RSE mutual authentication (AC-CR, etc).
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 16 of 105
3.2.8 Exchange enforcement data The term enforcement (act of enforcing) has a legal value generally linked to the legal action following a possible violation. Therefore, it may be affected by different interpretations when used in a national legal context. In this business process the reference is taken from the standard EN ISO 12855 even though it may be more correct to refer to enforcement control and/or enforcement data. Depending on the legal context, this Business Process may be used or not for data exchange between Toll Chargers and SP, for: getting additional information to allow the control by the Toll Charger if the Service User (Customer of a SP) fulfills its obligations to co-operate getting specific information, via the Toll Charger, to allow the enforcement by an authority, gathering facts required for later performance monitoring and/or SLA evaluation. 3.2.9 Reporting CCC Events For specific use, the Toll Charger may report CCC Events to the SP either on request from the SP or without such a request, for example for the verification of the OBU status in order to start corrective action(s). It is emphasized that any actions against a potential violator is under the exclusive responsibility of the Toll Charger. Remark: No report of CCC data exchange was made by participants. 3.2.10 Request and transmit contract, vehicle, user details Depending on the bilateral contractual context, the process may contain every exchange of user contract, OBU or vehicle related data, required by the TC, which is not available in the exchanged exception lists. 3.2.11 ReportAbnormal OBU The Toll Charger reports OBU with abnormal behavior in order to get them analyzed by the ETS Provider and potentially put on an exception list. 3.2.12 Exchange KPIs This process shall guarantee a formal exchange of KPIs between TC and SP.
3.3 Summary of business process analysis The summary of the information received by operating actors (ETS Providers, Toll Chargers) in the course of the business process analysis is shown in the following table. In this chapter the inputs received by the participants are presented in form of a breakdown table. The detailed input tables can be found in the annex, chapter 7.3. The following table shows how to interpret the information in Table 2.
Grey cell Process is not used or is not applicable
OK Process is used and is in line with EN ISO 12855
OK with Process is used but e.g. comments - for some TCs (e.g. F1), business processes are functionally compliant with EN ISO 12855, but not from a technical point of view (exchange of flat files is currently in place for TIS-PL) - extensions have been made which are currently handled in the ongoing revision of EN ISO 12855
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 17 of 105
No use of EN Process is used but not in line with EN ISO 12855 ISO 12855
Not yet Process is used, but the data exchange is not yet implemented with EN ISO implemented 12855
Business CH DE F1 F2 I PL E A/DK Process
No use of No use of OK OK OK Toll Context Data EN ISO EN ISO with OK with OK with 12855 12855 comments comments comments OK OK EFC Context See Trust See Trust No See Trust with with Mark objects objects information objects comments comments
No use of No use of OK Accepted EFC EN ISO EN ISO Context Marks with 12855 12855 comments OK OK OK Billing Details OK OK with with OK OK with comments comments comments
Payment Claim / OK OK No Payment OK OK with information with announcement comments comments
Toll Declaration OK OK OK
OK OK OK Exception Lists OK OK with OK with OK OK With comments comments comments Not yet OK No Trust Objects OK OK OK information implement with ed comments
Not yet No use of No use of Report Abnormal EN ISO OK EN ISO OBU implement ed 12855 12855
Request and OK Not yet transmit OK OK contract/vehicle/ with implement user details comments ed
Additional business processes (not in scope of 12855) Missing and/or No use of erroneous EN ISO records 12855
Requesting No use of technical OBU EN ISO information 12855 No use of Report DSRC EN ISO Data records 12855
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 18 of 105
Business CH DE F1 F2 I PL E A/DK Process
Transmit user No use of documents for EN ISO registration 12855
Table 2: Use of business processes in the toll domains 4 Business process detailed analysis In this chapter the input of the detailed business process analysis is presented. It contains details regarding the foreseen application of EN ISO 12855 in the existing EFC schemes in order to implement the EETS.
4.1 Detailed analysis approach Each Business Process has been analyzed in several different aspects. A comparison of the data exchange sequence has been done, followed by an analysis and comparison of used attributes of the main business process ADUs, including the possibility to document extensions to EN ISO 12855. Finally, the planned test procedure for each Business Process interface is considered. 1. Data exchange sequence The first table "ADU exchange sequences" of each business process is comparing the exchange sequence of the ADUs in the different schemes. 2. ADU attributes used This section, for each ADU, contains the main attributes detailed to a level allowing take evidence of major differences in terms of "the use of an attribute" in the different implementations. 3. Test procedures This aim of this section, for each applicable ADU, is to describe the test procedures grouped in the following test modules: i. Tests for the correctness of the format and syntax of the ADU. ii. Tests for the correctness of the content and semantics. iii. Tests for the correctness of the time requirements for answers or automatic data transmission.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 19 of 105
4.2 Analysis of ADUs and parameters
4.2.1 Toll Context Data ADU exchange sequence
ADU CH DE F1 F2 I PL E A/DK
Request (DE1) TC SP TC SP not used (time (only Retransmit A SP may request requirements) mode) the TC to send the currently valid or a previous version of the toll context data for a toll domain under its responsibility.
EFC context data TC SP TC SP TC SP TC SP TC SP (periodicity and Non periodic. Non periodic, every Non periodic, every either as a response ACT (Actor Table) time requirements) Initially and every time a variation to time a variation in to the Request and TST (Toll time a variation in the sections or toll the context occurs message sent by Station Table) the context occurs context occurs (new station, clo- the SP or as a push (new station, sure of station, new message if new Non periodic, every closure of station, tariffs); versions of Toll time a variation in new tariffs) Context are the context occurs available.
Acknowledge TC SP TC SP TC SP not used (time after reception of after reception of requirements) application flow max application flow max after 24 hours from after 24 hours from reception; reception;
Status TC SP The DataElement not used ackCode provides After reception status information for the whole FullEFCContextDat a message
D4.1 Definition of Back Office interfaces and of preliminary tests.doc Page 20 of 105
ADU CH DE F1 F2 I PL E A/DK
Additional SP-TC TC SP no exchange and exception handling a) Anomaly/Error b) Alert: after 2 handling procedure working days when no Ack received c) Timeout: max 3 working days after Alert sent;
Table 3: Toll Context data table Comments: (DE1) – general comment: no use of EN ISO 12855 data structures, Toll Context Data is transmitted as pdf and CSV file by email from the TC to the SP. Reception of documents needs to be confirmed by the SP Attributes
Attribute CH D F1 F2 I PL E A/DK
adu 1 1 1 1 └ eFCContextDataADU := CHOICE ├ gnssContext 1 0 0 0 │ ├ contextInterrelations 0 0 0 0 │ └ regimeContextData 1 0 0 0 │ ├ iso175753ADU 1…n 0 0 0 │ ├ gnssGDFLayout 0 0 0 0 │ └ feeModifiers 0 0 0 0 └ dsrcContext 0 0 1 1 └ regimeContextData ├ iso175753ADU 0 0 1 1 └ feeModifiers 0 0 0 0
└ dsrcClosedContext 0 1..n 1..n 0 └ DSRCChargeObject
Table 4. Context data exchange attributes
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 21 of 105
Test procedure
Test Focus CH DE F1 F2 I PL E A/DK
ADU No info No info No info SAT (A/DK1) format/syntax INT-1 (A/DK2) INT-2 (A/DK3)
ADU No info No info No info SAT (A/DK1) content/ semantics INT-1 (A/DK2) INT-2 (A/DK3) E2E (TEST)
(A/DK4)
ADU No info No info No info E2E (PROD) timing (A/DK5) TRIAL (in PROD Environment)
Table 5. Context data exchange test procedures Comments: (A/DK1) SAT = Test phase SAT (in Test Environment) performed by each actor (TC or SP) (A/DK2) INT-1 = Test phase INT-1 (in Test Environment) performed by each actor and EasyGo-HUB (TC <> EasyGo-HUB or SP <> EasyGo-HUB) (A/DK3) INT-2 = Test phase INT-2 2 (in Test Environment) performed by the new actor against all other actors (TC <> EasyGo-HUB<>SP) (A/DK4) E2E (TEST) = Test phase E2E (in Test Environment) performed by the new actor against all other actors (TC <> EasyGo-HUB <> SP) (A/DK5) E2E (PROD) = Test phase E2E (in Prod Environment) performed by the new actor against all other actors (TC <> EasyGo-HUB <> SP) 4.2.2 Accepted EFC Context Marks No own EN ISO 12855 supported data structure exists in current version new data structure in next version based on A/DK comments. Comments:
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 22 of 105
(F1 - 1) - The context for a given “combination” of EFC CM//Manufacturer-Equipment Class is specified according to tables T1, T2, T3 and T4 which are part of TIS-PL specifications. Tables are sent by each SP in the frame of the accreditation processes each time a new combination has to be accepted by all TC (of ASFA Road Network). The Toll Chargers implement, in their central system and Road Side Equipment, the processes to accept the personalized OBUs and to manage exchanges between central systems.
4.2.3 Billing Details ADU exchange sequences
ADU CH DE F1 F2 I PL E A/DK
Request not used TC SP TC SP not used (time (only in retransmit SP may request requirements) mode) previously sent Billing Details by means of a request message.
Billing Details TC SP TC SP TC SP TC SP TC SP TC SP TC SP (periodicity and daily 72h after toll daily daily (at least 95% At least one (min daily, up to Daily (latest 06:00) time declaration (DE2) of transits within 3 ReportBillingDetail weekly) requirements) working days) message per (via EasyGo HUB) reporting period is sent.
Acknowledge TC SP TC SP TC SP TC SP TC SP TC SP TC SP (time max. 24h (DE1) max. 2 days max. 24h max. 24h 0.5 up to 3h after requirements) TIF file was sent (not all SP send Ack) (via EasyGo HUB)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 23 of 105
ADU CH DE F1 F2 I PL E A/DK
Status not used TC SP not used not used Rollback mode The DataElement ackCode provides TC SP status information (notconfirmed for the whole mode) message to be acknowledged.
Additional no SP-TC TC SP no exchange and a) Alert if no Ack exception Anomaly/Error after 2 working days handling handling procedure b) Timeout if no Ack after 3 working days
Table 6: Billing Details table Comments: (DE1) - Acknowledgement is given in 2 ways (Extended Acknowledge Message): 1. Reception of message is acknowledged instantly after syntax/format check per SOAP-Response 2. Feedback regarding processing status of single records can be requested by SP (using RequestADU and ComplexAckADU) (DE2) - SP has to transmit corrected billing detail records at the latest until the end of the next working day, which follows the timestamp the error has been provided as feedback to the SP Attributes Table 7 below shows the main attributes of the Billing Details ADU and they are used in the different tolling schemes.
Attributes CH DE F1 F2 I PL E A/DK adu 1..n 0..n (DE1) 1 1..n 1..n 1..n 1..n └ billingDetailsADU ├ billingDetailsId 1 1 1 1 1 1 1 ├ tollChargerId 1 1 1 1 1 1 1 ├ contextId 1 1 1 1 1 1 1 ├ userId 1 1 1 1 1 1 1 │ ├ pan 1 1 1 1 1 1 1 │ ├ contractSerialNumber 0 0 0 0 0 0 0 │ ├ licencePlateNumber 1 1 0 0 0 0 1
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 24 of 105
Attributes CH DE F1 F2 I PL E A/DK │ └ obeID 1 1 1 0 1 0 1 ├ reportPeriod 1 1 1 1 1 0 0 │ ├ beginOfPeriod 1 1 1 1 1 0 0 │ └ endOfPeriod 1 1 1 1 1 0 0 ├ billingDetailsAmount 1 1 1 1 1 1 1 │ ├ paymentFeeAmount 1 1 1 1 tbc (PL1) 1 1 │ ├ paymentFeeUnit 1 1 1 1 tbc (PL1) 1 1 │ │ 0.01 CHF 0.01 EUR 0.1 EUR 0.01 EUR 0.01 EUR 0.01 EUR, DKK, NOK, SEK │ └ vATrate 0 0 1 1 tbc (PL1) 1 1 ├ usageDetails 1 1 1 1 0 1 1 │ ├ contextName 1 X 1 1 0 1 │ ├ appliedUserClass 1 X 1 1 1 0 │ └ perDeclaredVehicleClasses 1 1 1 1 0 1 │ ├ declaredVehicleClass 1 X 1 1 0 1 │ └ perUsedTimeClasses 1 1 1 1 0 1 │ ├ appliedTimeClass 1 X 1 X 0 1 │ ├ costCenter 0 0 0 0 0 0 │ └ usageList 3 1 1 1 0 1 │ └ UsageDetail (A/DK1) │ ├ usageDetail CHOICE { 1 1 1 1 0 1 │ │ ├ forSectionedRoads 0 1 (DE2) 1 1 0 1 │ │ ├ forTravellingInArea 0 0 1 0 0 0 │ │ ├ forStayedInArea 0 0 1 0 0 0 │ │ ├ forCordonCrossings 0 0 0 0 0 0 │ │ └ freeTextDetail 1 (CH1) 0 0 0 0 0 │ └ associatedEventData 0 0 0 0 0 1 ├ refTollDeclaration 1 0 0 0 0 0 0 ├ associatedEventData 0 0 0 0 0 0 0
└ actionCode 0 0 0 0 0 0 0
Table 7. Billing Details attributes Comments:
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 25 of 105
(CH1) - freeTextDetail: These freeTextDetail elements (sequence of 3 usageDetail) containing the information listed in clause 3.4 of the Swiss HVF EETS Domain Statement as formatted text. Text language is one of ['de' | 'fr' | 'it' | 'en']. (DE1) – billingDetailsADU: a SP has to report billing details. e.g. every 24h even there is no data to report, i.e. an empty info exchange for billing details. (DE2) - forSectionedRoads: Single segments of the journey (references to the UsageStatementId in the toll declaration) and whether they are entry, intermediate or exit segment (UsageDetail-CHOICE-forSectionedRoads enhanced by certain optional elements to current released version of EN ISO 12855, but already by CEN TC278/WG1 accepted changes for next version). (A/DK1) – The usageDetail data structure needs to be enhanced to cover entry and exit locations in different toll domains (PL1) – These sub-attributes are not detailed in the Protocol Implementation Compliance Statement for the Polish interface yet Test procedure
Test Focus CH DE F1 F2 I PL E A/DK
ADU integration test interface test phase interface test phase, No info No info No info SAT (A/DK1) format/syntax (CH1), (DE1), trial operation phase, operational INT-1 (A/DK2) field test (CH2) trial operation phase verification phase INT-2 (A/DK3) (DE2) with effective customers/vehicles
ADU integration test interface test phase interface test phase, No info No info No info SAT (A/DK1) content/ (DE1), trial operation semantics field test phase, operational INT-1 (A/DK2) trial operation phase verification phase INT-2 (A/DK3) (DE2) with effective customers/vehicles E2E (TEST) (A/DK4)
ADU field test trial operation phase interface test phase, No info No info No info E2E (PROD) timing (DE2), trial operation (A/DK5) phase, operational pilot operation verification phase TRIAL (in PROD phase (PROD with effective Environment) system) customers/vehicles (DE3)
Table 8. Billing details test procedures Comments (CH1) Integration test: In this stage, the interface between the FCA back office system and the ETS Provider is tested.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 26 of 105
(CH2) Field test (pilot test): In-service operation is tested using a limited number of test vehicles. All processes are conducted under real conditions and the HVF is levied via the EETS service. (DE1) Interface test phase: Here the correct transmission and the syntax and semantics according to the interface specification are tested. Correct application of rules and semantics are tested basically per spot checks. Compliance to timing requirements is not tested. Conducted in specific test system (interface test system) (DE2) Trial operation: Focus in this test phase is the verification of the correct E2E process. This means that testing of the correct application of the rules to generate the messages and the fulfilling of timing requirements are the primary aims of this test phase. Conducted in specific test system (trial system) (DE3) Pilot operation: E2E process under live conditions from generating messages according to the rules until the correct transmission to the toll charger is tested. Conducted in PROD environment 4.2.4 Payment Claim ADU exchange sequence
ADU CH DE F1 F2 I PL E A/DK
Request No information TC SP TC SP (A/DK1) (time (only in retransmit SP may request requirements) mode) previously sent Payment Claims by means of a request message.
Payment Claim TC SP No information TC SP TC SP (A/DK1) (periodicity and monthly 3rd and 18th of At least one time requirements) each month; max 6 reportPaymentClai months from Ack o m message per Timeout of each reporting period is Billing Details. sent.
Acknowledge TC SP No information TC SP TC SP (A/DK1) (time max. 2 days max after 24 hours requirements) from reception;
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 27 of 105
ADU CH DE F1 F2 I PL E A/DK
Status No information not used (A/DK1) The DataElement ackCode provides status information for the whole message to be acknowledged.
Additional SP-TC No information TC SP no exchange and exception handling Anomaly/Error a) Alert: handling procedure After 2 working days when no Ack received b) Timeout: max 3 working days from Alert sent;
Table 9: Payment Claim table Comments: (A/DK1) - The use of payment claim may become necessary and depends on the revision of EN ISO 12855, as one element can either be implemented in the Billing Details or the payment claim.
Attributes
Attributes CH DE F1 F2 I PL E A/DK adu 1 No info 1 1 └ PaymentClaimADU ├ paymentClaimId 1 No info 1 1 ├ startDateTime 1 No info 1 1 ├ endDateTime 1 No info 1 1 ├ userId 1 No info 1 0 │ ├ pan 1 No info 1 0 │ ├ contractSerialNumber 0 No info 0 0 │ ├ licencePlateNumber 0 No info 0 0
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 28 of 105
Attributes CH DE F1 F2 I PL E A/DK │ └ obeID 0 No info 0 0 ├ paymentClaimAmount 1 No info 1 1 ├ paymentClaimStatus 1 No info 1 1 ├ typeOfGoods 1 No info 1 1 │ └ referenceDetailsList 1 No info XX 1 │ │ SEQUENCE OF CHOICE { │ ├ billingDetailsList 1 No info XX 1 │ ├ tollDeclarationList 1 No info 0 0 │ └ tollEventList 1 No info 0 0
└ actionCode 1 No info 0 0
Table 10. Payment Claim attributes Test procedure
Test Focus CH DE F1 F2 I PL E A/DK
interface test phase, ADU No information No information No information trial operation format/syntax phase, operational verification phase with effective customers/vehicles
interface test phase, ADU No information No information No information trial operation content/ phase, operational verification phase semantics with effective customers/vehicles
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 29 of 105
Test Focus CH DE F1 F2 I PL E A/DK
ADU interface test phase, No information No information No information timing trial operation phase, operational verification phase with effective customers/vehicles
Table 11- Payment Claim test procedures 4.2.5 Payment announcements ADU exchange sequences
ADU CH DE F1 F2 I PL E A/DK
Request (time requirements)
Payment TC SP Announcement Until 3pm on (periodicity and working days for the time requirements) previous day (DE2)
Acknowledge TCSP (time (DE1) requirements)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 30 of 105
ADU CH DE F1 F2 I PL E A/DK
Status
Table 12: Payment announcement table Comments: (DE1): Acknowledgement is given in 2 ways (Extended Acknowledgement Message): 1. Reception of message is acknowledged instantly after syntax/format check per SOAP-Respons 2. Feedback regarding processing status of single records can be requested by SP (using RequestADU and ComplexAckADU) (DE2): SP has to transmit corrected payment announcement records at the latest until the end of the next working day, which follows the timestamp the error has been provided as feedback to the SP Attributes
Attributes CH DE F1 F2 I PL E A/DK adu 1 └ PaymentAnnouncementADU ├ paymentAnnouncementID 0 ├ dueDate 1 (DE2) ├ amount 1 0.01 EUR ├ paymentStatus 1 (DE3) ├ numberOfItems 1 ├ referenceDetailsList 1 │ │ SEQUENCE OF SEQUENCE { │ ├ referenceDetail CHOICE { 1 │ │ ├ billingDetailsList 0..n │ │ ├ tollDeclarationList 0 │ │ └ tollEventList 0 │ ├ paymentMeans 1 │ ├ valueDate 1 │ └ interestAmount 0..1 │ 0.01 EUR │ (DE4) ├ attachment 1 (DE5)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 31 of 105
Attributes CH DE F1 F2 I PL E A/DK └ actionCode Not used – new attribute in EN ISO 12855:2013
Table 13. Payment Announcement attributes Comments: (DE1 – general comment: Currently thePaymentAnnouncementADU is not used yet. Three specific ADUs have been introduced: DailyReportHeaderADU DailyReportADU OverviewDayilReportADU It is planned to use the upcoming PaymentAnnouncementADU which will probably be part of EN ISO 12855 (2014) and adjust the interface accordingly (DE2) - dueDate: Date of payments. This attribute describes the date of incoming payments on the bank account of the TC. (DE3)- paymentStatus: Two payment status are possible PAID: The amount for the journey has been transferred in time on the bank account of the TC NEW_OVERDUE: The amount for the journey has been transferred after the due time (valueDate) to the bank account of the TC. In this case interests occur. (DE4) - interestAmount: Only filled if payment status is “NEW_OVERDUE”. (DE5) - attachment: pdf File which contains information from the payment announcement in summarised form - dueDate - Bank account number - Total amount for payment announcement in status “PAID” (Sign “+”) - Total amount for payment announcement in status “NEW_OVERDUE” (incl. interests) (Sign “+”) - Total amount which has been transferred for this dueDate (Sign “+”) - Refund amount for test users, e.g. test rides/journeys (Sign “-”) - Amount which is due but not paid yet (Sign “+”) - Clearing amount (e.g. SP has transferred too much toll, and this amount shall be offset) (Sign “-”) - Name of creator at SP - Name of inspector at SP
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 32 of 105
Test procedure
Test Focus CH DE F1 F2 I PL E A/DK
ADU format/syntax interface test phase, trial operation phase, pilot operation phase (PROD system)
ADU interface test content/ phase, trial semantics operation phase, pilot operation phase (PROD system)
ADU trial operation timing phase, pilot operation phase (PROD system)
Table 14. Payment Announcement test procedures 4.2.6 Toll Declaration ADU exchange sequences
ADU CH DE F1 F2 I PL E A/DK
Retrieve specific Toll TC SP TC SP Declaration(s) (time requirements)
Request not used (time requirements)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 33 of 105
ADU CH DE F1 F2 I PL E A/DK
Toll Declaration TC SP TC SP TC SP (periodicity and time Automatic: Automatic: Automatic : requirements) max. 24h after CH max. 72h after exit detection a) Time basis (30’ (timeWhenUsed) after availability on In case of retrieve: SP proxy) max. 24h after (DE2) retrieve b) Dimensions (MAX 50.000 ADU per message)
Acknowledge TC SP TC SP (DE1) (time requirements)
Status not used
Table 15: Toll declaration table Comments: (DE1) - Acknowledgement is given in 2 ways (Extended Acknowledgement Message): 1. Reception of message is acknowledged instantly after syntax/format check per SOAP-Response 2. Feedback regarding processing status of single records can be requested by SP (using RequestADU and ComplexAckADU) (DE2) - SP has to transmit corrected toll declaration records at the latest until the end of the next working day, which follows the timestamp the error has been provided as feedback to the SP Attributes
Attributes CH DE F1 F2 I PL E A/DK adu 1..n 1 1…n └ tollDeclarationADU ├ tollDeclarationId 1 1 1 │ ├ issuerID 1 1 1 │ └ declarationID 1 1 1 ├ gnssTollDeclaration SEQUENCE OF 2..3 (CH1) 1 1…n │ └ ChargeReport
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 34 of 105
└ actionCode 0 0 0
Table 16. Toll Declaration attributes The following table details the fields of the ChargeReport attribute contained in the TollDeclaration attribute:
Attributes CH DE F1 F2 I PL E A/DK ChargeReport 1..n 1 ├ obeId 1 1 (DE2) 1 ├ vehicleLPNr 1 1 0 ├ paymentMeans 1 1 0 │ ├ personalAccountNumber 1 1 0 │ ├ paymentMeansExpiryDate 1 1 0 │ └ pamentMeansUsageControl 1 1 0 ├ serviceProviderContract 1 1 1 │ ├ contractProvider 1 1 1 │ ├ typeOfContract 1 1 1 │ └ contextVersion 1 1 1 ├ tollCharger 0 0 0 ├ timeOfReport 0 0 0 ├ reportPeriod X X 1 │ ├ beginOfPeriod X X 1 │ └ endOfPeriod X X 1 ├ versionInfo 0 1 0 ├ usageStatementList 1..n 1..n 1…n │ └ UsageStatement ├ vatForThisSession 0 0 0 ├ accountStatus 0 0 0 ├ transactionCounter 0 1 0 ├ mileage 0 0 0 ├ listOfCCCAttributes 0 0 0
└ authenticator 0 0 0
Table 17. Charge report attributes The following Table 18 details the fields of the UsageStatement attribute contained in the ChargeReport attribute:
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 35 of 105
Attributes CH DE F1 F2 I PL E A/DK UsageStatement 1 1..n 1 ├ usageStatementID 1 1 0 ├ regimeID 1 1 1 (fixed to 1) ├ aggregatedFee 0 0 0 ├ vat 0 0 0 ├ aggregatedSingleTariffClassSession 0 0 0 ├ listOfChargeObjects 0 or 2 (CH2) 1 0…1 ├ listOfDSRCUsageData 0..n (CH2+3) 0 0 ├ listOfRawUsageData 0..1 (CH4) 0 0…1 ├ noUsage 0 0 0 ├ additionalUsageInformation 0 1 (DE1) 1
└ usageAuthenticator 0 0 0
Table 18. Usage statement attribute fields Comments: (CH1) – ChargeReport: Two occurrences of ChargeReport, one containing all CCC transaction and the other the information about entrance and exit of Switzerland. Only in case of RetrieveTollDeclarationADU 3 ChargeReports. The comments CH2 to 4 explain the content of the 3 different ChargeReport. (CH2) - listOfChargeObjects and listOfDSRCUsageData (in ChargeReport containing the entrance and exit information):. Each of the two occurrences of DetectedChargeObject in listOfChargeObjects, one for entrance and one for exit of Switzerland, containing for the event time: event time of CH entrance or exit the vehicle parameters (weight, trailer, euro class, etc.), odometer reading and OBE timestamps position of entrance or exit trailer declaration A listOfDSRCUsageData with two occurrences of LAC attributes (from entry and exit DSRC transaction) logged by the OBE (CH3) – listOfDSRCUsageData: (in ChargeReport containing all CCC transaction): Containing the CCC attributes logged by the OBE of all CCC transactions during the EETS journey.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 36 of 105
(CH4) – listOfRawUsageData: Contains in case of RetrieveTollDeclarationADU only (in a third ChargeReport) the GPS position data of the EETS journey in Switzerland (not used/required in case of automatic toll declaration by SP). (DE1) - additionalUsageInformation: Indicates whether the charged segment has been the first, an intermediate or the last segment on the tolled journey - First segment: “ENTER” - Intermediate segment: “PASS_THROUGH“ - Last segment: “EXIT” (DE2) - obeId: Charge Reports are only accepted when the OBE-ID is known by the TC. This means the OBE-ID has already been on a whitelist which the TC has transmitted to the TC. (F2_1) – At least one of these two shall be present in the UsageStatement: - listOfChargeObjects: contain informations on LAC transactions - listOfRawUsageData: contain informations on GNSS collected data (F2_2) – additionalUsageInformation shall contain the original messages as originated by the OBU correctly signed and MIME coded Test procedure
Test Focus CH DE F1 F2 I PL E A/DK
ADU format/syntax integrations test, interface test phase No info field test trial operation phase
ADU integrations test, interface test phase No info content/ semantics field test trial operation phase
ADU field test trial operation phase No info timing pilot operation phase (PROD system)
Table 19. Toll declaration test procedures 4.2.7 Exception list ADU exchange sequences The following ADUs according to table 1 of EN ISO 12855 are used for the exchange of Exception List. For the list types, the following use is assumed: whitelist: A list with all OBE having a valid contract for the toll scheme.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 37 of 105
greylist: The list with suspicious OBE/vehicle of a SP for the toll scheme (with a valid contract for the toll scheme). Therefore these vehicles/OBEs have to be investigated specially in a spot check by the toll charger. blacklist: A list with all OBE having technically a valid contract for the toll scheme, but the SP is declaring this contract no more valid and does not longer provide a payment guarantee.
ADU CH DE F1 F2 I PL E A/DK
List type(s) blacklist blacklist blacklist (F1-1) blacklist greylist (IT1) blacklist blacklist blacklist whitelist greylist (F1-2) whitelist whitelist
Request not used TC SP: optional not used (time requirements)
Exception List TC SP TC SP TC SP: TC SP: TC SP: TC SP TC SP TC SP (periodicity and time once in 24h once a day or at daily after declaration of max daily The TSP is individual daily requirements) between 10 p.m. max. every 4h out of use responsible for agreements and 3 a.m. maintaining the list Latest 21:00 BL and providing Latest 22:00 WL updates to the Toll Charger (via EasyGo HUB)
Acknowledge TC SP TC SP TC SP TC SP: TC SP TC SP EasyGo HUB (TC) SP (time requirements) (DE1) within next day after reception of individual application flow agreements. Latest 0.5h max after 12 hours; Activation usually (acknowledge sent Activation of list within 24 h by EasyGo HUB) within 24 hours from Ack
Status not used not used not used not used The DataElement ackCode provides status information for the whole message to be acknowledged.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 38 of 105
ADU CH DE F1 F2 I PL E A/DK
Additional exchange and no SP-TC TC SP: no EasyGo HUB exception handling TC Anomaly/Error a) After handling procedure 12:01 hours when After 23:30 BL no Ack received After 00:30+1 WL b) Timeout: max 1 working day from Alert sent;
Table 20: Exception list table Comments: (IT1) - the greylist is used to define a SP blacklisted OBEs whose utilization cannot be physically inhibited by the TC who anyway considers them no more valid to receive payment from that SP and consequently becomes active part in recovering money, with the possible help of the SP to receive details about the final user. (DE1): Acknowledgement is given in 2 ways (Extended Acknowledgement Message): 1. Reception of message is acknowledged instantly after syntax/format check per SOAP-Respons 2. Feedback regarding processing status of single records can be requested by SP (using RequestADU and ComplexAckADU) (A/DK1) The exception list has to be distributed to the RSE latest 6:00 +1 day. (F1-1) – blacklist: List of PAN to be definitely blocked (F1-2) – greylist: List of PAN to be temporarily blocked Attributes The table below shows the main attributes of the Exception List ADU and they are used in the different tolling schemes.
Data element CH D F1 F2 I PL E A/DK adu 1 1 1 1 1 1 1 └ exceptionListADU (A/DK4) (A/DK5) └ ExceptionListADU 1 1 1 1 1 1 1 ├ exceptionListVersion 1 1 1 1 1 0 1 ├ exceptionListType 1 1 (DE1) 1 1 1 0 1 ├ exceptionValidityStart 1 1 1 0 0 0 1 ├ exceptionValidityEnd 0 0 1 0 0 0 0 └ exceptionListEntries 0..n (CH1) 0..n (DE2) 1 1..n 0..n 1..n 1..n
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 39 of 105
Data element CH D F1 F2 I PL E A/DK └ ExceptionListEntry ├ userId 1 1 1 1 1 1 1 │ ├ pan 1 1 1 1 0 1 1 │ ├ contractSerialNumber 0 0 0 0 0 0 0 │ ├ licencePlateNumber 1 1 0 0 0 0 1 (A/DK1) │ └ obeID 1 1 0 0 1 0 1 ├ statusType 1 1 1 1 (IT1) 1 0 1 (A/DK2) (blockType) (blockType) ├ reasonCode 1 1 1 1 1 0 1 (A/DK3)
└ dateAndTime 1 1 1 1 1 1 0
Table 21. Exception list attributes Comments: (CH1) – exceptionListEntries: An empty black list may be sent by the SP if all blacklist entries are no longer valid. (DE1) – exceptionListType: Only one type of exception list, either blacklist or whitelist in the same InfoExchange because of different interfaces for the two types. (DE2) – exceptionListEntries: A whitelist (containing all valid contracts) should not have zero entries. An empty black list may be sent by the SP if all blacklist entries are no longer valid. (IT1) – statusType= used as in the previous version of EN ISO 12855 (blockType), identifying the limitations of use due to the inclusion in the grey list. (A/DK1) – ExceptionListEntry-licencePlateNumber: only for whitelist (HGV-list) (A/DK2) – ExceptionListEntry-statusType: only for blacklist (NAT-list) (A/DK3) – ExceptionListEntry-reasonCode: only for blacklist (NAT-list) (A/DK4) – The exceptionListADU needs to be enhanced by at least one element to cover the use of the blacklist bit in France. (A/DK5) – The exceptionListADU needs to be enhanced by several elements to cover the tariff relevant elements for degraded mode operations in Scandinavia
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 40 of 105
Test procedures
Test Focus CH DE F1 F2 I PL E A/DK
ADU format/syntax integrations test, interface test phase interface test No info No info No info SAT (A/DK1) phase, trial field test trial operation operation phase, INT-1 (A/DK2) phase operational INT-2 (A/DK3) verification phase with effective customers/vehicles
ADU integrations test, interface test phase interface test No info No info No info SAT (A/DK1) content/ phase, trial semantics field test trial operation operation phase, INT-1 (A/DK2) phase operational INT-2 (A/DK3) verification phase with effective E2E (TEST) customers/vehicles (A/DK4)
ADU field test trial operation interface test No info No info No info E2E (PROD) timing phase phase, trial (A/DK5) operation phase, pilot operation operational TRIAL (in PROD phase (PROD verification phase Environment) system) with effective customers/vehicles
Table 22. Exception list test procedures 4.2.8 Trust Objects ADU exchange sequence
ADU CH DE F1 F2 I PL E A/DK
Request not used TC SP not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 41 of 105
ADU CH DE F1 F2 I PL E A/DK
Trust Objects TC SP TC SP TC SP TC SP (periodicity and time (CH1) (DE1) trustObjectADU can In case of changes requirements) be sent actively by TC or after A) Public receiving a Key reqTrustObjectADU SP/TC upload KDF . B) DSRC Keys SP upload KDF Latest 17:00, Day - 14 TC shall use the DSRC keys at his RSE: Latest 06:00, Day 1
Acknowledge TC SP TC SP TC SP TC SP (time requirements) (CH1) (DE1) In case of changes A) Public Key SP/TC upload KDC B) DSRC Keys TC upload KDC: Latest 20:00, Day - 14 SP check KDC earliest 20:30, Day - 14 and latest 21:30, Day -11
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 42 of 105
ADU CH DE F1 F2 I PL E A/DK
Status not used not used not used
The DataElement ackCode provides status information for the whole message to be acknowledged.
Table 23: Trust objects table Comments: (CH1) (DE1) – general comment: Exchange of trust objects in both directions to secure several interfaces. Possible exchange media: Email, storage media. No timing requirements defined yet. Attributes
Attributes CH DE F1 F2 I PL E A/DK adu 1 1 1 1 └ TrustObjectADU ├ trustObjectID 1 1 1 1 ├ startValidity 0..1 0..1 0,,1 1 ├ endValidity 0..1 / 1 (CH1) 0..1 / 1 (DE1) 0..1 0 ├ trustObjectStatus 1 1 1 0 ├ typeOfTrustObject 1 1 1 1 ├ purposesOfTrustObject 1 1 1 1 ├ eFCContextMark 0 (CH2) 0 (DE2) 1 ├ keyReference 0 (CH2) 0 (DE2) 1
└ trustObject 1 1 1 1
Table 24. Trust objects attributes
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 43 of 105
The following Table 25 details the fields of the ListOfTrustObjectPurposes attribute contained in the TrustObject attribute; it is indicated which type of trust objects will be exchanged:
ListOfTrustObjectPurposes CH DE F1 F2 I PL E A/DK trustObjects (0) 1 (CH3) 1 (DE3) 1 (PL1) 0 dSRCCharging (1) 0 0 0 1 dSRCAC (2) 0 0 0 1 oBEInterrogation (3) 1 1 0 0 oBEInterrogationAC (4) 1 1 0 0 sIGExceptionList (5) 0 0 0 0 sIGContextData (6) 0 0 0 0 sIGBillingDetails (7) 0 0 0 0 sIGFiscalObjects (8) 0 0 0 0 sIGCommunication (9) 0 1 1 0 eNCCommunication (10) 0 1 0 0 dSRCKeyEncryption (11) 0 0 0 1 secChannelEstablishment (12) 0 0 0 0 certIssuing(13) 0 0 0 0 sIGUserCommunication (14) 0 0 0 0 certRevocationListing (15) 0 0 0 0 Other trust objects Certificate "Key Distribution Tool" 1 (101) Certificate "SECA07000.ptcs.lcl" or 1 "SECB07000.ptcs.lcl" (102) Certificate "PTCSIssuingCA01" or 1 "PTCSIssuingCA02" (103)
CRL (105) 1 (PL2)
Table 25. Trust object purpose attribute fields Comments: (CH1) (DE1) – endValidity: The value is mandatory for some types of the exchanged trusted objects. (CH2) (DE2) – eFCContextMark & keyReference: These attributes are included in the data object/structure in trustObject. Data structures for trustObject from CEN/TS 16439 are used.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 44 of 105
(CH3) (DE3) – This purpose is used for the exchange of several certificates where the specific use is not covered by the current list. (A/DK1) – The data structure needs to be enhanced to cover a zeroBlockChecksum for verification of correct decryption. (PL1) – Further certificates with ListOfTrustObjectPurposes number are assigned in the private range (see “Other trust objects”) (PL2) – CRL with a different ListOfTrustObjectPurposes number assigned in the private range Test procedures
Test Focus CH DE F1 F2 I PL E A/DK
ADU format/syntax integrations test, interface test phase No info No info No info SAT (A/DK1) field test trial operation INT-1 (A/DK2) phase INT-2 (A/DK3)
ADU integrations test, interface test phase No info No info No info SAT (A/DK1) content/ semantics field test trial operation INT-1 (A/DK2) phase INT-2 (A/DK3)
E2E (TEST) (A/DK4)
ADU no tests, off-line no tests, off-line No info No info No info E2E (PROD) timing communication communication (A/DK5)
TRIAL (in PROD Environment)
Table 26. Trust object test procedures
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 45 of 105
4.2.9 Report Abnormal OBE ADU exchange sequence
ADU CH DE F1 F2 I PL E A/DK
Report abnormal TC SP: TC SP OBE max 12 months Daily, latest 06:00 (periodicity and time from date of transit. (via EasyGo HUB) requirements) (A/DK1)
Acknowledge TC SP: TC SP (time requirements) max after 24 hours 0.5 up to 3h from reception of application flow (via EasyGo HUB) (A/DK1)
Status Rollback not used
Additional exchange TC SP: and exception a) After 2 handling working days when no Ack received
b) max 3 working days from Alert sent;
Table 27: Report abnormal OBE table Comments: (A/DK1) – The report of abnormal OBU is partly included in the type of transit within exchange of the Transaction Information File (TIF): e.g.: C2/D2 – transit: Manually Taken Transits. No EN ISO 12855 communication. (F1 -1) - Reporting of abnormal OBU is done from TC to SP using bilateral specific processes (PAN, abnormal type, number of abnormal events per type / PAN, etc). No EN ISO 12855 communication.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 46 of 105
Attributes
Attribute CH D F1 F2 I PL E A/DK adu 1 1 └ ReportAbnormalOBEADU ├ userId 1 1 │ ├ pan 1 1 │ ├ contractSerialNumber 0 0 │ ├ licencePlateNumber 0 1 │ └ obeID 0 1 ├ dateAndTime 1 1
└ abnormalOBEReasonCode 1 1 (A/DK2)
Table 28. Report abnormal OBE attributes Comments: (A/DK1) – The report of abnormal OBU is partly included with the type of transit within exchange of the Transaction Information File (TIF): e.g.: C2/D2 – transit: Manually Taken Transits. No EN ISO 12855 communication. (A/DK2) – Indirect information within “type of transit” in TIF Test Procedure
Test Focus CH DE F1 I PL E A/DK
ADU format/syntax No info SAT (A/DK1) INT-1 (A/DK2) INT-2 (A/DK3)
ADU No info SAT (A/DK1) content/ semantics INT-1 (A/DK2) INT-2 (A/DK3)
E2E (TEST) (A/DK4)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 47 of 105
Test Focus CH DE F1 I PL E A/DK
ADU No info E2E (PROD) (A/DK5) timing TRIAL (in PROD Environment)
Table 29. Report abnormal OBE test procedures 4.2.10 Request and transmit contract/vehicle/user details ADU exchange sequence
ADU CH DE F1 F2 I PL E A/DK
Retrieve specific TC SP TC SP TC SP: (A/DK1) User Details / UserIDList (TSP collects open non periodic; max requests at least 12 months from (periodicity and time once a day) date of transit; requirements)
Provide User TC SP TC SP TC SP: (A/DK1) Details / UserIDList max. 24h max. 24h non periodic, (time requirements) mandatory after request max 30 days.
Acknowledge TC SP TC SP (IT1) (DE1)
Status not used not used
Table 30: Request and transmit user details Comments: (IT1) – Operational modes to be defined in contract between TC and SP. (DE1): acknowledgement is given in 2 ways
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 48 of 105
1. Reception of message is acknowledged instantly after syntax/format check per SOAP-Respons 2. Feedback regarding processing status of single records can be requested by SP (using RequestADU and ComplexAckADU) (A/DK1) – EN ISO 12855 Data content structures are not yet implemented (Few cases, e-mail is used) RetrieveUserDetails Attributes
Attribute CH D F1 F2 I PL E A/DK adu 1 1 1 └ retrieveUserDetailsADU └ RetrieveUserDetails SEQUENCE OF 1 0..n 1 listOfParametersRequested ├ userId 1 1 1 │ ├ pan 1 0..1 1 │ ├ contractSerialNumber 0 0 0 │ ├ licencePlateNumber 1 0..1 0 │ └ obeID 1 0..1 0 ├ listOfParametersRequested 2 1..n 1..n │ └ UserParameterRequest │ │ userPostalAddress 0 0 1 │ │ contractSerialNumber 0 0 0 │ │ contractValidity 0 0 0 │ │ driverCharacteristics 0 0 0 │ │ eFC-ContextMark 0 0 0 │ │ environmentalCharacteristics 0 0..1 0 │ │ engineCharacteristics 0 0 0 │ │ equipmentOBUId 0 0 0 │ │ equipmentStatus 0 0 0 │ │ paymentMeans 0 0 0 │ │ paymentMeansBalance 0 0 0 │ │ paymentMeansUnit 0 0 0 │ │ personalAccountNumber 0 0 0 │ │ provider 0 0 0 │ │ receiptContract 0 0 0 │ │ validityOfContract 0 0 0 │ │ vehicleAuthenticator 0 0 0 │ │ vehicleClass 0 0 0
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 49 of 105
Attribute CH D F1 F2 I PL E A/DK │ │ vehicleDimensions 0 0 0 │ │ vehicleLicencePlateNumber 0 0 0 │ │ vehicleIdentificationNumber 0 0..1 0 │ │ vehicleWeightLaden 0 0 0 │ │ vehicleWeightLimits 0 0..1 0 │ │ vehicleAxles 0 0..1 0 │ │ exhaustEmissionValues 0 0..1 0 │ │ dieselEmissionValues 0 0..1 0 │ │ extendedUserPostalAddress 1 0..1 1 │ └ preferredUserLanguage 1 (CH1) 0 0
└ userDetailsRequestReason 0 0 1 Table 31. Retrieve User Details attributes Comments: (CH1) – preferredUserLanguage: CH add on, requested for next version of EN ISO 12855 by CH comment. ProvideUserDetails Attributes Remark: It is assumed that listOfUserParameters sequence contains the parameters as defined in the request.
Attribute CH D F1 F2 I PL E A/DK adu 1..n 0..n 1 └ ProvideUserDetails ├ originaluserIdRequest 1 1 1 ├ userId 1 1 1 │ ├ pan 1 1 1 │ ├ contractSerialNumber 0 0 0 │ ├ licencePlateNumber 1 1 0 │ └ obeID 1 1 0 ├ statusFlag 1 1 └ listOfUserParameters SEQUENCE OF 2 1..7 1 └ UserParameterResponse ├ requestedUserParameter 1 1 1 ├ userParameterResponse 1 0..1 1
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 50 of 105
Attribute CH D F1 F2 I PL E A/DK
└ userParameterStatus 1 0..1 (DE1) 1 Table 32. Provide User Details attributes Comments: (DE1) - userParameterStatus: If no information for a requested parameter can be provided the respective attribute “userParameterResponse” remains empty and the reason is given in the attribute ”userParameterStatus” RetrieveUserIdList Attributes ADU is currently only used by Germany as top-up but has been already addressed as comment to EN ISO 12855
Attribute CH D F1 F2 I PL E A/DK adu 1 └ retrieveUserIdListADU └ RetrieveUserIdList SEQUENCE OF 0..n userId ├ userIdRequestType 1 (DE1) ├ userId 1 │ ├ pan 0..1 │ ├ contractSerialNumber 0 │ ├ licencePlateNumber 0..1 │ └ obeID 0..1 └ userIdRequestTime 1 Table 33. Retrieve Userid List attributes Comments: (DE1) - userIdRequestType: Attribute with fixed value: “allUserIdsToGivenCustomer(0)” Test procedures
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 51 of 105
Test Focus CH DE F1 F2 I PL E A/DK
ADU format/syntax integrations test, interface test phase No info field test trial operation phase
ADU integrations test, interface test phase No info content/ semantics field test trial operation phase
ADU field test pilot operation No info timing phase (PROD system) Table 34. Retrieve User List test procedures 4.3 ADU transport protocol The following tables are summarizing the provided information regarding the data exchange protocol 4.3.1 General General used internet connected interface:
Protocol features CH DE F1 F2 I PL E A/DK
Transport secured internet Application layer: Structured file sent TP : FTPS over Supported SFTP Application layer: SFTP Application layer: protocol channel Web service via secured internet VPN and FTPS; other SOAP 1.1 web File Exchange (SOAP) with SSL channel according media to be defined services using Service (EasyGo Security to TIS PL for the use of HTTPS HUB) via FTP Lower network specifications further processes layer: VPN Security : FTPS Lower network Lower network over signed files like Alert and Timeout in case of layer: VPN via layer: VPN IPSec pending dialogue
Table 35: ADU transport protocol 4.3.2 Process specific Overview of internet connected interfaces (Basic XY = protocol according to 4.3.1):
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 52 of 105
Process interface CH DE F1 F2 I PL E A/DK
Toll Context Data Paper or PDF pdf/csv File via Basic F1 Basic F2 Basic I Basic PL No info Basic A/DK Email
Accepted EFC n. a. n. a. email or paper n. a. n. a. email or paper Basic A/DK Context Marks
Billing Details Basic CH Basic DE Basic F1 n.a. Basic I Basic PL Basic E Basic A/DK
Payment Claim / n. a. Basic DE Basic F1 n.a. Basic I Basic PL n.a. Payment announcement
Toll Declaration Basic CH Basic DE n. a. SOAP over SSL (for Basic I n. a. n. a. n.a. retrieve TollDeclaration)
Exception Lists Basic CH Basic DE Basic F1 n.a. Basic I Basic PL Basic E Basic A/DK
Trust Objects to be decided data storage not used n.a. Paper or PDF Basic PL n.a. Basic A/DK (most likely data medium storage medium and/or secured and/or email) secured email
Report Abnormal n. a. n.a. bilateral specific n.a. Basic I n. a. n. a. Basic A/DK OBU processes
Request and Basic CH Basic DE not used n.a. Basic I n. a. n. a. Email transmit contract/ vehicle/user details
Table 36. Internet connected interfaces
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 53 of 105
5 General results and findings This chapter contains the results and findings of the analysis conducted within this document.
5.1 General results 1. Beyond the scope of the information exchanges defined in EN ISO 12855 additional information exchanges are foreseen by several toll chargers As a relevant fact, the WP4 identified some new business processes (not foreseen in ISO 17573 defining the basic EFC system behavior/business processes for EN ISO 12855) but they have not been discussed into details. In particular: New business processes by Germany resulting in the following additional information exchanges: Transmission of missing and / or erroneous records Requesting technical OBU information Report DSRC Data records They do not imply modifications to the current version of EN ISO 12855. New and adapted business processes identified by Austria resulting in the following additional information exchanges: Transmission of accepted EFC Context Marks Changes in transmission of Quality Assurance parameters Changes in transmission of Toll Context Data The possible modifications in the EN ISO 12855 will be discussed accordingly in the appropriate standardization groups.
New business process by France (Ecotaxe system) resulting in the following additional information exchange: Transmission of user documents for user registration 2. All participating toll chargers are oriented to implement their back office interfaces based on the provisions of EN ISO 12855 and the majority has already done so. All participating toll chargers apply EN ISO 12855 at least from a functional point of view, or for some of their back office interfaces, or indicated that their used formats may be mapped (e.g. by a mediation layer) to EN ISO 12855 instead. Anyway the implementation of the toll chargers is heterogeneous and involves individual extensions and specific requirements. Some of the extensions are on their way to become part of an updated version of EN ISO 12855, as they have been provided as comments to CEN/TC278/WG1 and ISO/TC204/WG5 for the ongoing revision of the EN ISO 12855. 3. Web service and FTP are basis technologies for back office communication applied the most The analysis shows that the usage of web service communication and data exchange using File- transfer-Protocol are the transport protocols used the most by the participating partners. Besides some processes require information exchange using organizational means, which could be paper or the transmission of csv- or pdf-files over email or storage medium. 4. No detected misunderstandings of the semantics of ADUs for which information have been provided Although some of the ADUs have been used in the different allowed maximum range of variations, for the current level of detail, no evidence about incorrect interpretation of some ADU’s content has been reported by the systems for which input has been provided.
D4.1 Definition of Back Office interfaces and of preliminary tests.doc Page 54 of 105
5. No detected abuse of the semantic of fields For the current level of detail, no evidence has been reported by any system about abuse of some ADU’s content. Nonetheless, some of the "open" fields (e.g. from ChargeReport, UsageStatement, etc.) are used with system specific content definitions. 6. Vehicle and user identification The PAN is used by all Toll Chargers as identification medium for the vehicle and/or user, sometimes in combination with the license plate number and/or the OBE-ID.
5.2 Results of business process analysis 1. Exchange of Toll Context Data All participating toll chargers (except Spain) use the business process where the Toll Context Data is always transferred from the Toll Charger to the ETS Provider. The application of EN ISO 12855 for this process is heterogeneous. Some use EN ISO 12855 for data exchange (F1, F2, I, PL, A/DK) and some use organizational manners (CH, DE). 2. Exchange of Billing Details The exchange of Billing Details is applied by all participants, with the exception of F2. In the group of users, the Billing Details are transferred from the Toll Charger to the ETS Provider with the exception of Germany where the direction is vice versa. 3. Exchange of Payment Claims The Payment Claim process is applied by some Toll Chargers (F1, I, PL). The application in AT and DK depends on the positive result of the ongoing revision of the EN ISO 12855. In all cases the Toll Charger sends Payment Claims to the ETS Provider. In the cases where the process is applied this is done according to EN ISO 12855. 4. Exchange of Payment announcements The exchange of Payment Announcements is currently only foreseen in Germany. Payment Announcements will here be sent from the ETS Provider to the Toll Charger. The integration of the Payment Announcements business process into the standard is currently done in the course of the revision of EN ISO 12855. 5. Exchange of Toll Declarations The Exchange of Toll Declarations is only used in GNSS-based toll domains. All three Toll chargers with GNSS-based toll systems (CH, DE and F2) intend to use the EN ISO 12855 information exchange. In these cases the ETS Providers send the toll declarations to the Toll Charger. Anyway, the planned implementation and requirements for the message’s attributes are different between those three: F2: Transmission of original message (GPS-positions) as generated by the OBE from SP to TC (Raw Usage Data) CH: Transmission of three different kinds of Toll Declarations ADUs: o CCC events (List of DSRC Usage Data) o Event of entry and exit in/from Switzerland o GPS position data which has been recorded by the OBE within Switzerland (only if requested by TC) DE: Toll Declaration contains the information about each single segment driven by the vehicle already with qualifier, whether they have been entry, intermediate segment or exit of journey and the tariff. 6. Exchange of Exception lists All Toll Chargers (except of F2) apply the exchange of exception lists with the ETS Providers. The following Table 37 shows the usage of blacklist, whitelist and greylist.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 55 of 105
CH DE F1 F2 I PL E A/DK
Whitelist X X X
Blacklist X X X X X X X
Greylist X X
Table 37: Different use of exception list business process 7. Exchange of Trust Objects The exchange of Trust Objects is not performed by all participants according to EN ISO 12855. Currently only CH, DE and PL intend to use this process. 8. Report Abnormal OBE Only Italy and A/DK use this process where the TC informs the SP. Italy uses it in accordance with the information exchange defined in EN ISO 12855. F1 and A/DK use it without compliance to EN ISO 12855. 9. Request and transmit contract/vehicle/user details The process is only applied by CH, DE and IT with the information exchange defined in EN ISO 12855. A/DK uses it as well, but it is realised with email communication due to the low number of cases. 10. Exchange of CCC events No input received for this data exchange in the involved toll domains..
5.3 Findings regarding applied test procedures for back office interfaces 1. General approach Test procedures for back office interfaces might be organized in a “hierarchical structure”, with the objective to distinguish the test user (Toll Charger or ETS Provider), the business processes test (e.g. Payment Claims, among the others), the behavior type associated with the test case (valid or invalid). Further details about this possible approach are in the paragraph 7.4 of the Annexes. 2. Staging approach is applied for testing of back office interfaces Four TCs provided input regarding the foreseen testing procedure for the business processes which involve the back office interfaces (CH, DE, F1 and AT/DK). All of them apply a testing approach which tests the back office interfaces in different test stages. CH test procedure consists of 2 stages: i. Integration test: In this stage, the interface between the FCA back office system and the ETS Provider is tested. ii. Field test (pilot test): In-service operation is tested using a limited number of test vehicles. All processes are conducted under real conditions and the HVF is levied via the ETS service. DE test procedure consists of 3 stages: i. Interface test phase: Here the correct transmission and the syntax and semantics according to the interface specification are tested. Correct application of rules and semantics are tested basically per spot checks. Compliance to timing requirements is not tested. Test phase is conducted using a specific test system (interface test system). ii. Trial operation: Focus in this test phase is the verification of the correct E2E process in a test environment. This means that testing of the correct application of
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 56 of 105
the rules to generate the messages and the fulfilling of timing requirements are the primary aims of this test phase. Test phase is conducted using a specific test system (trial test system). iii. Pilot operation: E2E process under live conditions from generating messages according to the rules until the correct transmission to the toll charger incl. timing requirements is tested. All processes are conducted under real conditions. Pilot phase is conducted in PROD environment. F1 test procedure consists of 3 stages: i. Interface test phase ii. Trial operation phase iii. Operational verification phase AT/DK test procedure consists of 5 stages: i. Test phase SAT (in Test Environment) performed by each actor (TC or SP) ii. Test phase INT-1 (in Test Environment) performed by each actor and EasyGo- HUB (TC <> EasyGo-HUB or SP <> EasyGo-HUB) iii. Test phase INT-2 2 (in Test Environment) performed by the new actor against all other actors (TC <> EasyGo-HUB<>SP) iv. Test phase E2E (in Test Environment) performed by the new actor against all other actors (TC <> EasyGo-HUB <> SP) v. Test phase TRIAL (in PROD Environment)
The following Table 38 shows the distribution of the different test focuses on the test stages for the three toll chargers who provided input.
Test focus syntax/format semantics timing CH 1. integration test X X 2. pilot test (PROD-system) X X X DE 1. interface test X X 2. trial phase X X X 3. pilot phase (PROD- X X X system) AT/DK 1. SAT X X 2. INT-1 X X 3. INT-2 X X 4. E2E phase X X 5. trial phase (PROD- X X system) F1 1. interface test X X X 2. trial operation X X X 3. Operational verification X X X
Table 38: Distribution of stages for the three toll chargers who provided input.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 57 of 105
5.4 Recommendation to CEN for IAP The Interoperable Application Profile (IAP) for EN ISO 12855 should customise the base standard to be used in an interoperable EFC cluster based on several different toll domains. The current document shows the similarities and differences of existing and planned EETS back office interfaces of the EFC systems operated by the involved Toll Chargers. Therefore the general results and findings as well as the detailed analysis of the EETS back office interface in this document are helpful inputs for the definition of the IAP based on EN ISO 12855. From the REETS-TEN project perspective, the IAP should: cover at least the information exchange provided in detail in chapter 4.2 as far as they are based on EN ISO 12855 (of course revised version); limit if possible the ADU transport protocol to the methods given in clause 4.3; cover the underlying business processes to reduce the number of possible interpretations of data exchange; take as input to form the final IAP the three sub profiles: o Profile 1: DSRC based o Profile 2: GNSS/CN based – SP dominant o Profile 3: GNSS/CN based – TC dominant In addition to the IAP, an IAP test standard limited to the test focus "syntax/format" is also recommended. Such a test standard may be applied in a preliminary test phase by each actor, i.e. TC and SP before a first integration test.
5.5 Requirements for SPs 1. The level of risk and process responsibility allocated to the SP’s are differing according to the different Toll Domains
The level of risk and the share of process responsibility that stands between the SPs and the Toll Chargers, differ a lot in the different Toll Domains with respect to the applied toll regime and features of the Toll Domain.
DSRC-based GNSS/CN based
Profile 1 Profile 2 (SP dominant) Profile 3 (TC dominant)
Level of risk / share or process Medium Highest High responsibility supported by the SP
Toll Chargers F1, I, PL, E, A, DK DE F2, CH
Table 39: possible subdivision of level of risk in different toll domains
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 58 of 105
6 Conclusions With regards to the roadmap towards the implementation of EETS some considerations shall have to be made related to the back office interfaces between TCs and SPs. Prior to the definition of EETS interoperability constituents, already existing systems performed their data exchange using optimized platforms based upon agreed needs of the involved parts, mainly in bilateral agreements, and in some cases with a cluster approach. The current data exchange between TCs and SPs, even if performed following their own rules per Toll Domain or cluster of Toll Domains, can be partly mapped to the standard EN ISO 12855, from a functional point of view. In the EETS framework (as defined by the Directive 2004/52/CE and Decision 2009/750/CE) there is a “not strictly binding” indication for the stakeholders to relate to a standard for the realization of the back office interfaces. The standard EN ISO 12855, made available after the entering in force of the Decision, could become binding when inserted in a legal framework, with the objective to ease the deployment of the EETS, beyond the existing interfaces.
Further considerations: 1. Although all participating Toll Chargers have been oriented in implementing their back office interfaces in line with the provisions of EN ISO 12855, the communication over the several TCs defined back office interfaces is still heterogeneous. At the current state of art, the SPs have had to adapt to the requirements of Toll Domains (or Cluster of Toll Domains) and this resulted in different implementations. 2. 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 a. support the needs of Toll Chargers and ETS Providers b. reduce implementation effort for both Toll Chargers and ETS Providers. c. be efficient from the operational costs point of view 3. Additional information exchanges (neither foreseen in the current version nor in the ongoing revision of EN ISO 12855) have been identified. Some of them are using the back office interfaces (e.g. transmit user documents for registration in F2 system) and some are conducted using organizational manners like email and/or telephone (e.g. Report DSRC Data records from TC to SP in DE). The realization of those additional information exchanges means that some or parts of the SPs business processes and interfaces need to be added or designed individually for a specific toll charger. 4. Due to the individual EFC system definitions and requirements, the implementation for REETS and EETS may be complex for Service Providers. 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 REETS and EETS, the harmonization of GNSS/CN tolling scheme types and system requirements should be checked. 5. The adoption “de facto” of an agreed version of the EN ISO 12855 in a REETS MoU (therefore involving SPs) could be a provisional compromise in order to realize more consistent back office data exchange platforms for EETS. Moreover, the EN ISO 12855 being
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 59 of 105
a toolbox (intended to support all kind of EFC systems), the availability of suitable IAPs for EN ISO 12855 per type of Toll Context (DSRC context, GNSS Context) would contribute to facilitate this step for the future development of the EETS to the entire EU. This point will have to be evaluated carefully when enlarging the playground to the entire EU for the future development of the EETS, especially related with the IAP for the GNSS context. 6. What is described in this deliverable should be the reference for future functional implementations, at least within the pilot project; and this could also be the case when enlarging the scheme to the entire EU for the future development of the EETS.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 60 of 105
7 Annexes
7.1 Article 3, 5, 6 of EETS Decision
(2009/750/EC)
COMMISSION DECISION of 6 October 2009 on the definition of the European Electronic Toll Service and its technical elements Article 3 EETS Providers shall collaborate with Toll Chargers in their enforcement efforts. Article 5 Rights and obligations of Toll Chargers 6. A Toll Charger may require an EETS Provider’s collaboration to perform unannounced and detailed toll system tests involving vehicles circulating or having recently circulated on the Toll Charger’s EETS domain(s). The number of vehicles submitted to such tests over a year for a particular EETS Provider shall be commensurate with the yearly average traffic or traffic projections of the EETS Provider on the Toll Charger’s EETS domain(s). Article 6 Toll Context Data Toll Chargers shall communicate any changes to their Toll Context Data to the Member State(s) in which their toll domains are located relating inter alia to the following: (a) definition of the EETS domain, in particular its geographic extension and infrastructure subject to toll; (b) nature of toll and levy principles; (c) vehicles liable to toll; (d) vehicle classification parameters (such as number of axles, maximum permissible weight of trailer, suspension type, etc.) with their mapping into the Toll Charger’s tariff structure; (e) toll declarations required.
7.2 Application Guide Interface 3 (between back-office systems) Decision 2009/750/EC requires the following standardized back-office sub-interfaces to be implemented: a) exchange of toll declaration data between EETS Providers and Toll Chargers, more specifically for submission and validation of claims for charges incurred in DSRC- or/and GNSS-based toll systems; b) invoicing/settlement; c) exchange of information in support of exception handling in DSRC- or/and GNSS-based toll systems: d) exchange of EETS blacklists; e) exchange of Trust-Objects; f) communication of Toll Chargers’ Toll Context Data to EETS Providers. Toll Chargers must implement each interface, but can choose only to support either the GNSS or DSRC charging process. These sub-interfaces are depicted in the Figure 4below.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 61 of 105
Figure 4: Sub-interfaces as in the Application Guide The set-up of these sub-interfaces may depend on the usage of DSRC or GNSS-based tolling systems. The transferred data will be different depending on the actual tolling context and technology. prEN ISO 12855, currently available as a draft, describes all the mentioned interfaces. The described sub-interfaces would need to be implemented between each EETS Provider/Toll Charger pair. However the agreed use of intermediate entities, like clearing houses, etc. can make the communication more efficient. The responsibility lies with the EETS Providers and Toll Chargers.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 62 of 105
7.3 Business processes tables The following Table 40 defines the technical support processes (whose ADUs are referred in table in yellow) and Business Processes (whose ADUs are referred in table in orange) as they are reported in the standard EN ISO 12855. Some of them are common in both the DSRC and GNSS scenarios, some other are peculiar for only one or two profiles. The following table summarizes the list of processes with the profiles involved.
ADU Description Profile involved
requestADU Generic Request All
statusADU Generic Status All
ackADU Generic Acknowledge All
extendedAckADU Extended Acknowledge All
trustObjectADU Send Trust Objects All
eFCContextDataADU Send EFC Context Data All
exceptionListADU Send Exception List All
reportAbnormalOBEADU Report Abnormal OBE All
retrieveTollDeclarationADU Retrieve Specific Toll Declarations 2,3
tollDeclarationADU Toll Declaration 2,3
billingDetailsADU Billing Details All
paymentClaimADU Payment Claim 1,3
retrieveUserDetailsADU Retrieve Specific User Details All
provideuserDetailsADU Provide User Details All
retrieveCCCEventADU Retrieve Specific CCC Event 2,3
reportCCCEventADU Report CCC Event 2,3
retrieveUserIdListADU Retrieve a user list All
provideUserIdListADU Provide a user list All
reportQAADU Report QA All
paymentAnnouncementADU Payment Announcement 2
Table 40: List of ADUs as defined in the standard EN ISO 12855 The tables in the following clauses contain the input related to the high level analysis of business processes sent by the involved countries.
D4.1 Definition of Back Office interfaces and of preliminary tests.doc Page 63 of 105
7.3.1 Transmit Toll Context Data
MS GNSS Exchanged Information Transactions, Sequences, Media - EN ISO 12855 support data structure DSRC Performance requirements - Semantics
No ISO 12855 communication.
1. Sent as part of Toll Context Data / Toll domain 1. Rules defining the vehicles liable to the statement toll and the exempted vehicles. 1. Vehicles liable to toll 2. Sent as part of Toll Context Data / Toll domain 2. Vehicle euro class 2. Vehicle classification statement parameters 3. Definition of person(s) or legal entities 3. Sent as part of Toll Context Data / Toll domain liable to pay toll under the operation of CH GNSS 3. One(s) liable for toll Paper or PDF statement the toll regime 4. Definition of the tolled 4. Sent as part of Toll Context Data / Toll domain 4. Definition of the tolled area = public roads area statement in Switzerland and the Principality of 5. Toll transaction policy Liechtenstein. 5. Sent as part of Toll Context Data / Toll domain statement 5. Functional description of the rules to determine an EETS journey of a vehicle in Switzerland.
List of motorway and federal road sections (ID, start, end, No technical requirements CSV-File PDF by DE GNSS length) No use of EN ISO 12855 data structures Reception of documents needs to be confirmed email Tariff model (law text)
D4.1 Definition of Back Office interfaces and of preliminary tests.doc Page 64 of 105
MS GNSS Exchanged Information Transactions, Sequences, Media - EN ISO 12855 support data structure DSRC Performance requirements - Semantics
Gantry: lists of DSRC Toll Plaza (ETC lanes or gantries) Each TC=>SP Sent by each TC each time a Toll Plaza is created, Main data provided: modified, deleted
- Toll Plaza code (Toll Structured file sent via secured Charger ID, Toll Plaza ID) internet channel
- Toll Plaza name (for information of Customers)
Subscription to rebate plan(s):
F1 DSRC subscription for a specific PAN (Customer/vehicle) to a
specific rebate plan from a particular TC Sent on a daily basis by SP to each TC concerned when SP=>each TC subscriptions or modifications linked to a rebate plan are requested by customer for a PAN Main data provided: Structured file sent via secured Major of data exchanged between TC and SP are based on EN 14906. Compatibility - PAN Acknowledged within the next 2 days by TCs (syntactic internet channel and semantic controls done) with EN ISO 12855 is assured. - Old PAN (in case of
replacement) Original file can be partially or entirely rejected
- LPN
- Rebate plan code - Start date//End date
List of first, second and third class road sections (ID, F2 GNSS version , start of operation, gnsscontextdata) Tariff model (law text)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 65 of 105
MS GNSS Exchanged Information Transactions, Sequences, Media - EN ISO 12855 support data structure DSRC Performance requirements - Semantics
List of DSRC gantries; () with: () every time a variation in the context occurs (new Station-Id within the station, closure of station, new tariffs); motorway (Network code+Station Code) Request (): optional (only in Retransmit mode) Supported SFTP and FTPS; other EN ISO 12855.2 media to be defined for the use of I DSRC Acknowledge (): mandatory after reception of Description of station further processes like Alert and EFCContextData ADU with the only application flow max after 24 hours from reception; dsrcClosedContext option Type of station Timeout in case of pending dialogue; Alert (): after 2 working days when no Ack received Code of related TC Timeout (): max 3 working days after Alert sent; Date of opening Date of closing
Each "Toll Context Chapter" is provided only as full Soap web services using HTTPS Functionality: update. SOAP 1.1 is used as transport Originating and providing EFC context No delta updates of Context Data elements are protocol data envisaged. Application protocol used for the Application data units: Each context data message will only comprise one information transfer is character- version of EFC Context. oriented, the XML Encoding Rules EFCContextDataADU (XER) according to ISO/IEC 8825-4 is The SP is responsible of maintaining the history of used to encode data. ADU fields used: received toll context data. VPN via IPSec tollContextOverview An SP may request from the TC to send the currently tariffTable valid or a previous version of the toll context data for a ETS Provider has to accept the TC certificates issued by the Kapsch PKI. Used by the TC to send toll toll domain under its responsibility. This operation is localVehicleClassDefinition PL DSRC performed by means of a “Request” message. context data to an SP In each case a secure VPN-Tunnel timeClassDefinition For this interface only dsrcContext data is specified. (according to [EFC Security FW] GnssContext data is not supported. chapter 8.6.2 Secure communication chargeLocations channel) between the Firewalls, using The structure to transport the EFCAttributes itself is fixed IP-Addresses, is established. 100% according to [ISO 17575-3]. Only asynchronous messages are Constraint: Each "Toll Context Chapter" can be exchanged. transmitted as a dedicated message. Message return parameters are Constraint: Each "Toll Context Chapter" shall be always void. transmitted within a dedicated adu container. Messages shall be acknowledged by dedicated, asynchronous acknowledgement message.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 66 of 105
MS GNSS Exchanged Information Transactions, Sequences, Media - EN ISO 12855 support data structure DSRC Performance requirements - Semantics
E DSRC Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 67 of 105
MS GNSS Exchanged Information Transactions, Sequences, Media - EN ISO 12855 support data structure DSRC Performance requirements - Semantics
Each TC and SP → EasyGo Management Latest 12:00 Day -7 EasyGo management updates global ACT Latest 12:00 Day 0 The Toll Regime Overview is EasyGo HUB provide (global) ACT: Data exchanged between TC and SP are defined in the Actor Table based on EN 14906 PISTA and developed and on the website of the - Latest 20:00 Day 0 All TCs and SPs may to the EasyGo profiles. Compatibility with EN responsible TC. download updated (global) ACT ISO 12855 is assured. - Earliest 20:30, Day 0 All TCs and SPs put global AIT in operation The data exchange server “EasyGo HUB” - Earliest 6:00 Day 1 ACT (Actor Table) - Latest 6:00 Day 6 Are internally working based on XML. The server translates currently the textiles before Content: ActorID, TC → EasyGo HUB processing them. If TC or TSP delivers in Company and contact XML the EasyGo Hub will be able to process data are collected and TC upload (local) TST: the directly. However a table setting up who distributes to all actors Any time but latest 18:00, Day0 Email, are sending in which format must be established prior to receiving XML. EasyGo HUB → originator, TST (Toll Station Table) Data content are compliant and data exchange according using XML instead of A/DK DSRC all, TCs and SPs Content: The properties text file are under investigation. of their toll collection EasyGo HUB provide (global) TST: See Austrian comments AT02, AT03 and system to allow correct Max. 20 minutes after reception data in invoices etc. AT04 to CEN ISO TS 17575-3 which are EasyGo HUB ACT File needed to be implemented, so the data Originator downloads (global) TST: exchange over EN ISO 12855 can import the Max. 30 minutes after uploading missing data structures and use them. Originator validates (global) TST and sends correction to If these comments are not accepted in the EasyGo HUB if necessary: current revision of CEN ISO TS 12757-3, which ends at 17th of May 2014, the same Latest 19:00, Day 0 comments are given to include these data structures directly in EN ISO 12855, as they EasyGo HUB provides new (global) TST if correction are needed (see comments AT11, AT12 and was necessary: AT13 to EN ISO 12855). Latest 20:30, Day 0 All TCs and SPs may download updated (global) TST • Earliest 20:30, Day 0 All TCs and SPs put global TST in operation Earliest 6:00 Day 1 Latest 6:00 Day 6
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 68 of 105
Table 41. Transmit Toll Context Data 7.3.2 Transmit EFC Context Mark
MS GNSS Exchanged Information Transactions, Sequences, Media - ISO 12855 support data structure DSRC Performance requirements - Semantics
Exchange of EFC context mark is part of Sent by the SP to be configured in the CH GNSS Paper See Trust Object Process exchange of trust objects RSE
Exchange of EFC context mark is part of DE GNSS See Trust Object Process exchange of trust objects
Transmit RSE acceptance rules (EFC Context Mark, OBU, OBU brand/type, Each SP=> all TC Describes for each combination of EFC Sent by each SP, each time CM//Manufacturer-Equipment Class to be Major of data exchanged between TC accepted by RSEs: a new combination has to be Manually sent during Accreditation and SP are based on EN 14906. F1 DSRC accepted by all TC process Compatibility with EN ISO 12855 is rules to process the OBU by RSE (data assured. available in the OBU, data coding, (of ASFA Road Network) security mechanisms, …) data to be provided to SP in charging data/Toll declaration, security mechanisms, …)
F2 GNSS
EFC context mark is part of exchange of I DSRC See Trust Object Process trust objects
PL DSRC Not used
E DSRC Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 69 of 105
Data exchanged between SP and TC Context mark, PAN number and information are based on EN 14906 PISTA and regarding use of security level are developed to the EasyGo profiles. exchanged between SP and TC in a Compatibility with EN ISO 12855 is separate file. (AIT file – Accepted Issuer The same as Transmit accepted EFC A/DK DSRC assured. table) Context Mark Data content are compliant and data Trust objects and security information are exchange using XML instead of text file exchanged in a separate file are under investigation.
Table 42. Transmit EFC Context Mark 7.3.3 Transmit accepted EFC Context Marks
GNSS Transactions, Sequences, - ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
CH GNSS Not used
DE GNSS Not used
The Toll Chargers implement, in their central system and Road Side Equipment, the F1 DSRC processes to accept the personalized OBUs No use of EN ISO 12855 and to manage exchanges between central systems.
F2 GNSS
I DSRC Not used
PL DSRC Not used
SP => TC Excel file sent by No use of EN ISO 12855 data E DSRC List of valid EFC context mark email or paper structures
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 70 of 105
GNSS Transactions, Sequences, - ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
SP → EasyGo HUB SP upload (local) AIT: • Any time but latest 18:00, Day0 EasyGo HUB → originator, all TCs and TSPs EasyGo HUB provide (global) AIT: • Max. 20 minutes after reception AIT (Accepted Issuer Table) Originator downloads (global) AIT for verification: AIT file sent by the SP to There is currently no message defined Content: Approved SPs including the to allow the SP to define his • Max. 30 minutes after uploading the EasyGo HUB number series of their on board units OBE EFCContextData to be accepted by the TC. SP => TC Originator validates (global) AIT and sends correction to A/DK DSRC EasyGo HUB if necessary:
List of valid EFC context mark • Latest 20:00, Day 0 Global AIT file distributed Therefore such a message needs to
EasyGo HUB provides new (global) AIT if correction was from the EasyGo HUB to be defined in line with AT05 of the necessary: all TCs and SPs. Austrian comments to EN ISO 12855. • Latest 20:30, Day 0 All TCs and SPs may download updated (global) AIT • Earliest 20:30, Day 0 All TCs and SPs put global AIT in operation • Earliest 6:00 Day 1 • Latest 6:00 Day 6
Table 43. Transmit accepted EFC Context Mark
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 71 of 105
7.3.4 Transmit Billing Details
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
EN ISO 12855 - BillingDetailsADU with a usagList A data record of the assessment containing 3 elements of decision for the EETS journey is sent - Assessment data record sent to SP secured internet freeTextDetail. CH GNSS to the SP with the obligation to - SP shall acknowledge the received assessment data record within 24 channel disclose the complete assessment hours These freeTextDetail elements date to the EETS User. containing the information listed in clause 3.4 of the Swiss HVF EETS Domain Statement.
ETS provider submit Billing Detail records to Toll Charger One billing detail record represents a complete journey of one vehicle on the tolled road network (starting with the entry; ending with exit). Reception of billing details will be confirmed by the Toll Charger Billing detail contains thereby data (including warning or error message during processing) Usage of EN ISO 12855 related to: Billing details records have to be transmitted at the latest 72 hours BillingDetailsADU message enhanced DE GNSS Web service - the vehicle after transmission of the toll declarations which are referenced within by certain elements. the billing detail record - single segments of the journey Specification publicly available (references to the UsageStatementId in the toll declaration) and whether they are entry, intermediate or exit segment the toll amount due for the complete journey
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 72 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
List of trip transactions. Each TC=> relevant SP (identified by EFC CM) Main data provided: - PAN // LPN - Entry Toll Plaza data (if close toll regime) - Exit Toll Plaza data - Dates, Time - Vehicle characteristics Sent on a daily basis Structured file sent via - Authentication Data EN ISO 12855 (tbc) F1 DSRC Acknowledged within the next 2 days by SP (syntactic and semantic secured internet BillingDetailsADU - Transaction counter controls done). Original file can be partially or entirely rejected channel List of valorization data for customer invoicing - Approved Transactions ID - Commercial Conditions - Transactions modality - Transaction amount - Transaction TVA OBE handling mode (DSRC lane beacon, table beacon, PAN tabulation,…)
F2 GNSS
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 73 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
List of trip transactions; ( ) with: billingDetailsId ( ) daily (at least 95% of transits within 3 working days) Supported SFTP and FTPS; other media to ISO EN 12855.2 Request ( ): optional (only in Retransmit mode) tollChargerId be defined for the use BillingDetailsADU Acknowledge ( ): mandatory after reception of application flow max I DSRC contextId of further processes after 24 hours from reception; like Alert BillingDetailsId is customized with userId claimId “longer” hosting a code Alert ( ): after 2 working days when no Ack received; and Timeout in case allowing the univocity of element period Timeout ( ): when no Ack received within 3 working days of pending dialogue; billingDetailsAmount usageDetails
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 74 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
Soap web services using HTTPS SOAP 1.1 is used as transport protocol Application protocol used for the information transfer is character-oriented, the XML Encoding Rules (XER) At least one ReportBillingDetail message per reporting period is sent. according to ISO/IEC 8825-4 is used to encode data. Functionality: A BillingDetail message can contain BillingDetails of one or more road VPN via IPSec users. Report Billing details ETS Provider has to accept the TC Application data units: A BillingDetailADU contains only transactions from one road user. certificates issued by BillingDetailADU the Kapsch PKI. ReportBillingDetail messages sent by SP shall acknowledge the correct reception and syntactical ADU fields used: In each case a TC to SP containing details of understanding of the message. PL DSRC secure VPN-Tunnel billingDetailsId transactions incurred by the SP’s Message checks can be done at interface level and acknowledged via (according to [EFC users synchronous reply on lower communication protocol layer (e.g. HTTP Security FW] chapter contextId error code) or via asynchronous AckADU message. 8.6.2 Secure userId communication SP and TC shall address disputes regarding semantic or logical channel) between the period content of the message manually. Firewalls, using fixed billingDetailAmount SP may request previously sent Billing Details by means of a request IP-Addresses, is message. established. The SP shall be able to request re-transmission of a previously sent Only asynchronous Billing Detail. messages are exchanged. Message return parameters are always void. Messages shall be acknowledged by dedicated, asynchronous acknowledgement message.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 75 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
List of toll transactions. TC => SP Main data provided: - Date and time The period depends on the agreement between SP and TC. Usually No use of EN ISO 12855 data E DSRC - PAN SFTP every day, two days in a week, weekly structures - Entry toll station - Exit toll station - Amount Vehicle class
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 76 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
TC -> EasyGo HUB -> SP TC upload TIF: Latest 06:00, Day 0 EasyGo HUB provide TIF: Latest 06:30, Day 0 SP check TIF for download: Earliest 06:30, Day 0 latest 09:00, Day 0
SP ->EasyGo HUB ->TC Transaction Information Files SP upload TIC: TIF Latest 09:30, Day 0 TIF File sent from the Content: Transactions made EasyGo HUB provide TIC: TC via the EasyGo by SP’s approved OBE HUB to the SP. Latest 10:00, Day 0 The Billing details structures need to be updated to accommodate some TC check TIC for download: needed elements. A/DK DSRC Latest 10:30, Day 0 See comments AT19 to AT24 of the Austrian comments to EN ISO 12855.
TIF includes the following type of transits: Transaction Information Confirmation TIC File sent from the • C1/D1 - Normal Transits Charges SP via the EasyGo TIC HUB to the TC. • C2/D2 - Manually Taken Transits Content: Each SP to confirm receipt of TIF • C3/D3 - Corrected Amounts Charges • C4/D4 - Virtual transits Charges • C5/D5 - No Entry Data (Most Expensive Transit) • C6/D6 - incomplete transactions • C7/D7 - ”Converted” transit • C8/D8 - Manually taken transits taken at CS • C9/D9 - Correction of rejected transit TIF includes the following aggregated transactions:
• E1 – Aggregated debit transaction REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014• T1 – Aggregated-07-16.doc credit transaction Page 77 of 105
Table 44. Transmit Billing Details 7.3.5 Transmit Payment Claim / Payment announcement
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
CH GNSS Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 78 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
ETS provider submits Payment Announcements records to the Toll Charger One payment announcement record represents one tolled journey for which the respective toll amount has been transferred to the bank account of the toll charger
Payment Announcement records Currently: contain thereby data related to (DailyReportADU): Specific ADUs have been introduced - the due date (date for which - DailyReportHeaderADU the payment announcement Reception of payment announcement (DailyReport, - DailyReportADU contains data) DailyReportHeader, OverviewDayilyReport) will be confirmed by the Toll Charger (including warning or error message during processing) - OverviewDayilReportADU DE GNSS - references to billing details, Web service for which the due toll amount Payment Announcement messages must be transmitted each Specification publicly available has been transferred to the working day until 3pm previous day (including the records for the Toll Charger’s bank account previous day) Besides the single payment It is planned to use the planned announcement records this PaymentAnnouncementADU which message contains as well will probably be part of EN ISO 12855 (2014) - a header record containing overview information, e.g. sender, receiver, due date, number of records (DailyReportHeaderADU) an overview report as pdf-file containing overview information e.g. due date, clearing information, name responsible person on SP’s side (OverviewDailyReportADU)
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 79 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
Invoicing data (billing details data+rebates+management fees+billing data corrections) Each TC=> relevant SP (identified by EFC CM) Sent on a monthly basis (5 calendar days + 2 working days after end EN ISO 12855 (tbc) of period. Structured file sent Main data provided per PAN // PaymentClaimADU F1 DSRC LPN Acknowledged within the next 2 days by SP (syntax and semantic via secured internet controls done) Only billing details that were previously - Invoicing data type channel acknowledged are taken into account - Amount (Without VAT and with Original file can be partially or entirely rejected in the payment claims. VAT if any) List of charging data (trip transactions) taken into account for invoicing are provided
F2 GNSS
Invoicing data; ( ) with: ( ) 3rd and 18th of each month; max 6 months from Ack o Timeout of Supported SFTP and paymentClaimId each Billing Details. FTPS; EN ISO 12855.2 startDateTime Request ( ): optional (only in Retransmit mode) other media to be defined PaymentClaimADU I DSRC userId Acknowledge ( ): mandatory after reception of application flow max for the use of further after 24 hours from reception; associateBillingDetails:SEQUENCE paymentClaimAmount processes like Alert and OF BillingDetailsId instead of Alert ( ): After 2 working days when no Ack received Timeout in case SEQUENCE OF RelatedMessageId paymentClaimStatus Timeout ( ): max 3 working days from Alert sent; of pending dialogue; typeOfGoods associateBillingDetails
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 80 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
Soap web services using HTTPS SOAP 1.1 is used as transport protocol Application protocol used for the information transfer is character-oriented, the XML Encoding Rules Functionality: (XER) according to ISO/IEC 8825-4 is used to Claim payment for service usage At least one reportPaymentClaim message per reporting period is encode data. Application data units: sent. VPN via IPSec PaymentClaimADU A reportPaymentClaim message contains all BillingDetails of all ETS Provider has to users of the SP. accept the TC certificates ADU fields used: issued by the Kapsch PKI. The SP shall acknowledge the correct reception and syntactical paymentClaimId reportPaymentClaim messages understanding of the message. In each case a secure PL DSRC sent by TC to each SP containing startDateTime VPN-Tunnel (according to details of payment due to the TC SP and TC shall address disputes regarding semantic or logical content of the message manually. [EFC Security FW] chapter endDateTime 8.6.2 Secure SP may request previously sent Payment Claims by means of a communication channel) paymentClaimAmount request message. between the Firewalls, paymentClaimStatus using fixed IP-Addresses, The SP shall be able to request re-transmission of a previously sent is established. typeOfGoods Payment Claim. Only asynchronous associatedBillingDetails messages are exchanged.
Message return parameters are always void. Messages shall be acknowledged by dedicated, asynchronous acknowledgement message.
E DSRC Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 81 of 105
- EN ISO 12855 support data GNSS Transactions, Sequences, MS Exchanged Information Media structure DSRC Performance requirements - Semantics
A/DK DSRC Not implemented
Table 45. Transmit Payment Claim / Announcement 7.3.6 Transmit Toll Declaration
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
Data of a completed EETS journey in Switzerland. This data contains (in a short description): Automatic: - Contract reference (PAN) - SP sends the EETS journey data latest after EN ISO 12855 TollDeclarationADU with 2 different - Vehicle and OBE identification 24h following the end of the charge period (= ChargeReport containing the toll declaration data (for when the vehicle leaves Switzerland). as single EETS journey). - Tariff determining vehicle parameters (weight, trailer, euro class, etc.) - Acknowledge of received toll declaration secured internet CH GNSS On request only: - DSRC transaction data (1..n x CCC and 2 channel In addition but on request only, the SP has to resend x LAC) including of most in the OBE the toll declaration including the GPS position data of - TC request for resending the journey data available CCC and LAC attributes the EETS journey in Switzerland: This is done by a including GPS position data ISO 12855 TollDeclarationADU with 2 different - Odometer reading and OBE timestamps at - SP shall respond the position data within 24h ChargeReport containing the toll declaration and 1..n entrance and exit of Switzerland including after request ChargeReport containing the GPS position data. position entrance and exit and trailer declaration - Acknowledge of received toll declaration data On request only: GPS position data of the EETS journey
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 82 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
ETS Providers submit Toll Declaration records to Toll Charger Reception of toll declarations will be confirmed One toll declaration record represents one by the Toll Charger (including warning or error driven segment on a tolled road message during processing) Usage of EN ISO 12855 TollDeclarationADU message Transmission at the latest 72 hours after DE GNSS Toll declaration contains all required data Web service enhanced by certain elements. (vehicle related, road usage related) that are detection timestamp (timeWhenUsed) Specification publicly available required to calculate the actual tariff. Toll declarations will be rejected if the respective NOTE: According to the requirements, the vehicle has not been transmitted on a whitelist tariff must be calculated by the ETS before Provider)
F1 DSRC Not used
Toll Service providers send Toll Declaration to Toll Charger Toll Declaration represents one or more F2 GNSS passed gantry on a segment of a taxed road. Toll declaration contains all required data (OBU ID, vehicle data) for the tax calculation by the Toll Charger.
I DSRC Not used
PL DSRC Not used
E DSRC Not used
A/DK DSRC Not used
Table . Transmit Toll Declarations
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 83 of 105
7.3.7 Transmit Exception Lists (blacklists and/or whitelists)
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
EN ISO 12855
- The exception list is to be transmitted between 10 p.m. - ExceptionListADU Black list and 3 a.m. (nightly) As a minimum, each entry in the exception secured internet list consists of a PAN, a vehicle CH GNSS (checked during CCC transaction at - The exception list may only be transmitted once within any 24-hour period. channel registration number including country vehicle entry to Switzerland) identifier and the EETS OBE device - Acknowledge of received exception list number consisting of EquipmentOBUId (AttributeID = 24) + obeConfiguration.manufacturerID.
Blacklist: ETS provider transmits a complete list of blacklisted users to the Toll Charger One record in the blacklist contains information related to the blacklisted Usage of EN ISO 12855 ADU exceptionList message vehicle (combination of license plate and Reception of blacklists and whitelists will be confirmed OBE-ID) including the reason why and by the Toll Charger (including warning or error message Differentiation between black- and whitelist the time stamp when it was blacklisted. during processing) is done using the attribute exceptionListType: DE GNSS Web service - blacklist (1) Whitelist: Blacklists and whitelists should be transmitted at least ETS provider transmits a complete list of once a day or at maximum every 4 hours. - whitelist (2) his users for which he provides the toll service within the German toll domain. One record in the whitelist contains Specification publicly available information related to the vehicle (combination of license plate and OBE- ID) including the initial time stamp when it was added to the whitelist the first time.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 84 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
Each SP=> all TC EN ISO 12855 (tbc) Sent on a daily basis List of PAN to be blocked: ExceptionListADU Acknowledged within the next day by TC (syntax and Structured file sent via F1 DSRC - PAN semantic controls done) - List TYPE / definitely (Black List) / secured internet channel If an OBU infinitely blocked is detected by RSE, RSE modifies a flag in the OBU Temporarily (Grey List) Original file can be partially or entirely rejected - Emission Date which leads to discontinuation. - Reason Code Registration: Service provider submits to the TC all relevant information for the subscription of a new vehicle in accordance with the local legislation (identification of the tax payer, vehicles documents and all Registrations: documents needed); Sent by the SP to the TC on a regular basis when Secured internet channel; No use of EN ISO 12855 (specification When the TC has approved the needed with a structured syntax via secured FTP available on requests)
subscription, the SP notifies the TC with transfers. the OBU-ID that is associated with the
relative contract.
Blacklist: F2 GNSS Whenever the OBU is declared stolen, out of order or if the user has canceled its contract with the SP, SP transmits the list of OBU concerned. Blacklist: IEN SO 12855 compliant (specification Private network (MPLS link) Due to local legislation constraints, the Two ways communications depending on where it available on requests) user has to declare to the TC when on occurs based on an web service the taxable network the OBU is out of order or stolen. This specific procedure declared “procedure de scours” requires form the user (subscriber) specific actions in coordination with the TC. When registered, the TC informed the SP that its OBU has been put on the blacklist.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 85 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
EN ISO 12855.2 List of PAN to be blocked; () max daily. ExceptionListTypeADU Supported SFTP and FTPS; () with: Request (): optional; exceptionListType only value 3 (GL) other media to be defined exceptionListVersion Acknowledge (): mandatory after reception of WL: list of admitted PANs (not used) for the use of further application flow max after 12 hours; I DSRC exceptionListType BL: list of inhibited PANs (not used) processes like Alert and Activation of list within 24 hours from Ack exceptionListEntries GL: list of non admitted PANs (used) Timeout in case Alert (): After 12:01 hours when no Ack received exceptionValidityStart (*) (*): exchanged off line of pending dialogue; Timeout (): max 1 working day from Alert sent; exceptionValidityEnd (**) (**): exchanged off line and corresponds to the start of new list
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 86 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
Soap web services using HTTPS SOAP 1.1 is used as transport protocol Application protocol used for the information transfer is character-oriented, the XML Encoding Rules (XER) according to ISO/IEC 8825- 4 is used to encode data. Functionality: VPN via IPSec Manage exception lists The issuer/owner of an ExceptionList is always the SP. ETS Provider has to accept Application data units: The SP is also responsible for maintaining the list and the TC certificates issued by providing updates to the TC. The TC is responsible for the Kapsch PKI. ExceptionListADU Used for the TC to receive ExceptionList accepting the list and deploying it according to PL DSRC In each case a secure VPN- ADU fields used: messages from SPs contractual conditions Tunnel (according to [EFC For Blacklists, each ExceptionListEntry will be blocked Security FW] chapter 8.6.2 exceptionListVersion until it is not present in the next received version, Secure communication exceptionListType regardless of blockType or reasonCode. channel) between the Firewalls, using fixed IP- exceptionListEntries Addresses, is established.
Only asynchronous messages exchanged. Message return parameters are always void. Messages shall be acknowledged by dedicated, asynchronous acknowledgement message.
SP => TC The period and the activation time depend on the List of PAN not to be accepted on toll E DSRC agreement between SP and TC. Usually every day, two SFTP No use of EN ISO 12855 data structures lanes days in a week, weekly List of PAN requiring special treatment
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 87 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
The communication between the SP and TC is carried The blacklist (NAT, Not Accepted Table out via the EasyGo HUB which collects, validates and List) and the whitelist (HGV, Heavy merges files and forwards the information to the correct Goods Vehicle List) together form the recipient(s). Validity lists of Service Users (= SP EasyGo HUB Exception List). SP upload local NAT:
latest 21:00, Day 0
EasyGo HUB all TCs
EasyGo HUB global NAT: Blacklist (NAT) latest 22:00, Day 0 NAT TC download global NAT: Content: Lists of not accepted OBEs latest 23:00, Day 0 The Exception list structures need to be EasyGo HUB SP updated to accommodate some needed elements. A/DK DSRC max. 30 min after reception EasyGo HUB See comments AT16, AT17 and AT18 of Each TC shall use the validity list latest 06:00, Day 1 the Austrian comments to EN ISO 12855. NAC (Confirmation File) SP EasyGo HUB
SP upload local HGV:
latest 22:00, Day 0 EasyGo HUB all TCs Whitelist (HGV) EasyGo HUB global HGV: HGV Content: Lists of issued OBEs latest 23:00, Day 0 TC download global HGV:
latest 00:30, Day 1 EasyGo HUB SP HGC (Confirmation File) max. 30 min after reception Each TC shall use the validity list latest 06:00, Day 1
Table 46. Transmit exception lists
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 88 of 105
7.3.8 Exchange Trust Objects
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
Not in detail defined yet. But the following trust objects will be required: - CCC and LAC keys including EFC- ContextMark CH GNSS Not defined yet - Trust objects for securing back-office communication - Trust objects to authenticate charge report data by a Front-End
Within this process the following trust objects are exchanged: - Trust objects (certificates) for the information exchange between backoffice No technical requirements interfaces between service provider and File exchange Toll Charger central systems Reception of trust objects is DE GNSS acknowledged by the Toll Charger. In (e.g. storage media Usage of EN ISO 12855 TrustObjectCode - Masterkeys for the information exchange case a exchanged trust object has not or E-Mail) between the SPs OBE and the TCs RSE been accepted a reason is provided. (incl. EFC context mark information) Transport keys for a secured exchange of the above mentioned information
Not used – sent during accreditation process F1 DSRC via a secured specific mechanism
F2 GNSS
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 89 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
The Trust Objects data exchange is originated by the TC with a flow towards the SP containing the Trust Objects with own certificate public key. Manually sent during accreditation Implemented via TrustObjectADU, but not I DSRC The SP verifies the content through a process used at the moment Certification Authority and then sends a public key encrypted master key to the TC. Finally the TC uses its private key for decryption.
Soap web services using HTTPS SOAP 1.1 is used as transport protocol Functionality: Application protocol used for the information transfer is character- Exchange Trust Objects oriented, the XML Encoding Rules (XER) according to ISO/IEC 8825-4 is Application data units: used to encode data. TrustObjectADU VPN via IPSec ADU fields used: ETS Provider has to accept the TC trustObjectID Details in summary of PTCS EETS certificates issued by the Kapsch PKI. Used to exchange trust objects between TC PL DSRC Security Concept document startValidity and SPs In each case a secure VPN-Tunnel 40700050040. (according to [EFC Security FW] endValidity chapter 8.6.2 Secure communication channel) between the Firewalls, using trustObjectStatus fixed IP-Addresses, is established. typeOfTrustObject Only asynchronous messages are purposesOfTrustObject exchanged. trustObject Message return parameters are always void. Messages shall be acknowledged by dedicated, asynchronous acknowledgement message.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 90 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
E DSRC Not used
SP -> EasyGo HUB -> TC SP upload KDF:
With KDF (Key Distribution File) and KDC (Key Latest 17:00, Day -14 Distribution Confirmation) EasyGo HUB -> TC: KDF Latest 18:00, Day -14 Content: Approved SP shall provide their TC shall use the keys at his RSE: security keys for each TC The Trust Object structures need to be Latest 06:00, Day 1 updated to accommodate some needed elements.
A/DK DSRC EasyGo HUB See comments AT06 and AT14 of the TC ->EasyGo HUB -> SP Austrian comments to EN ISO 12855. TC upload KDC:
Latest 20:00, Day -14
EasyGo HUB -> SP: KDC Latest 20:30, Day -14 Confirmation from TC SP check KDC: Earliest 20:30, Day -14 and Latest 21:30, Day -11
Table 47. Transmit Trust Objects 7.3.9 Report Abnormal OBU
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
CH GNSS Not used
DE GNSS Process is not foreseen
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 91 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
from TC to SP: PAN, abnormal type, F1 DSRC number of abnormal events per type / bilateral specific processes No use of EN ISO 12855 data structures PAN, etc
F2 GNSS
Notification of malfunctions or Supported SFTP and FTPS; anomalous behaviors; () max 12 months from date of transit. other media to be defined EN ISO 12855.2 () with: Acknowledge (): mandatory after reception of for the use of further ReportAbnormalOBEADU I DSRC application flow max after 24 hours from reception; userId processes like Alert Alert (): After 2 working days when no Ack received Operational modes subsequent to Timeout dateAndTime and Timeout in case to be defined between TC and SP Timeout (): max 3 working days from Alert sent; abnormalOBEReasonCode of pending dialogue;
PL DSRC Not used
E DSRC Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 92 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
TC EasyGo HUB SP TC upload TIF: Latest 06:00, Day 0 EasyGo HUB provide TIF for download to SP: Latest 06:30, Day 0 SP downloads TIF: Within exchange of the TIF: The report Earliest 06:30, Day 0 latest 09:00, Day 0 of abnormal OBU is partly included with A/DK DSRC EasyGo HUB No EN ISO 12855 communication the type of transit, e.g.: C2/D2 – transit: Manually Taken Transits SP EasyGo HUB TC SP upload TIC: Latest 09:30, Day 0 EasyGo HUB provide TIC for download to TC: Latest 10:00, Day 0 TC downloads TIC: Latest 10:30, Day 0
Table 48. Report Abnormal OBU
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 93 of 105
7.3.10 Request and transmit contract/vehicle/user details
GNSS Transactions, Sequences, -EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
Vehicle holder information: Information on the holder who has power of disposal over EN ISO 12855 the vehicle in accordance with the vehicle registration document. Priority of holder data - Request from TC to SP for vehicle holder - RetrieveUserDetailsADU from the EU vehicle registration certificate: information secured internet - ProvideUserDetailsADU CH GNSS C3 before C2 before C1. The information - SP shall response within 24h after request must include all three name subheadings channel Requested is the user postal address, most Cx.1 (name or company name), Cx.2 (first - Receiving of respond will be acknowledged likely the name(s) or (if applicable) initials) and Cx.3 (address in the country of registration at the - ExtendedUserPostalAddress time the certificate was issued).
Process 1: Transferring vehicle and user details from SP to TC after request from TC - Vehicle details, e.g. emission characteristics, number of axles, vehicle category, weight characteristics - User details, e.g. address, telephone, Reception of user-details and list of user-ids will be email, fax confirmed by the Toll Charger (including warning or Process 1: error message during processing) SP does not transmit all details but only Usage of EN ISO 12855 ADU those attributes which have been requested Requests from TC to SP must be collected at least RetrieveUserDetails and ProvideUserDetails DE GNSS by the TC once a day by SP. Web service Process 2: Reply from SP to TC should be provided within 30 Process 2: min and at maximum 24 hours after collection of the Transferring additional user-ids which are request Additional ADU is used: RetrieveUserIdList registered by one haulier from SP to TC after and ProvideUserIdList request by TC - TC requests all additional user-ids by providing one user-id to the SP - SP provides all other user-ids which are registered by this specific haulier The information is needed for preparation of enforcement activities at hauliers offices
F1 DSRC Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 94 of 105
GNSS Transactions, Sequences, -EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
F2 GNSS
Supported SFTP and Request of info about users with transits in FTPS; EN ISO 12855.2 exception list; () non periodic; max 12months from date of other media to be () with: transit; defined RetrieveUserDetailsADU I DSRC (): non periodic, mandatory after request max 30 userId for the use of further ProvideUserDetailsADU days. listOfParametersRequested processes like Alert Operational modes to be defined in contract between TC and SP userDetailsRequestReason and Timeout in case of pending dialogue;
PL DSRC Not used
E DSRC Not used
Exchange of Enforcement data via request and transmit contract/vehicle/user details: When a TC detects a (potential) offense by a vehicle / SU the TC may issue a request for the address data of the owner of the vehicle to one or more SPs. Data content structures are not yet implanted (Few cases e-mail are used) The TC and SP may exchange data A/DK DSRC as long as this exchange is within the Email When data exchange are developed Data legislation /regulations of the country from exchange using XML instead of text file will be which the data is generated. analized The legislation / regulations regarding data privacy is different in each country and it is the responsibility of the entity providing the data to ensure that the data requested can be submitted.
Table 49. Request and transmit contract/vehicle/user details
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 95 of 105
7.3.11 Transmission of missing and / or erroneous records (additional business process in DE)
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
CH GNSS Not used
TC performs plausibility/ completeness checks of the received toll declarations, billing details and daily reports (payment announcements). No technical requirements CSV-File In case there are missing or erroneous records (e.g. DE GNSS PDF by Email No use of EN ISO 12855 data structures miscalculated toll amounts) TC will submit a report stating Reception of documents needs to be the respective records via email. confirmed EMail The issue clarification between TC and SP is done with organizational means (email, phone).
F1 DSRC Not used
F2 GNSS
I DSRC Not used
PL DSRC Not used
E DSRC Not used
A/DK DSRC Not used
Table 50. Transmission of missing records 7.3.12 Requesting technical OBU information (additional business process in DE)
GNSS Transactions, Sequences, -EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
CH GNSS Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 96 of 105
GNSS Transactions, Sequences, -EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
In Germany the process of refunding toll amounts is performed by the TC. Users have to request for a refund of overpaid toll at the TC.
Within this process TC requests information from the SP No technical requirements DE GNSS regarding the technical status of an OBU at a certain time to Email, telephone No use of EN ISO 12855 data structures clarify whether the user’s refund request is justified or not. TC requests technical information (OBU status, technical abnormalities) for a specific OBU at a certain time via organizational means (email, telephone)
F1 DSRC Not used
F2 GNSS
I DSRC Not used
PL DSRC Not used
E DSRC Not used
A/DK DSRC Not used
Table 51. Requesting technical OBU information 7.3.13 Report DSRC Data records (additional business process in DE)
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
CH GNSS Not used
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 97 of 105
GNSS Transactions, Sequences, - EN ISO 12855 support data structure MS Exchanged Information Media DSRC Performance requirements - Semantics
DE GNSS SPs can request DSRC records for specific OBUs from No technical requirements telephone, email, CSV- No use of EN ISO 12855 data structures TC. File via email
SP submit vehicle information (license plate, OBE-ID) and time span to TC via Email. TC investigates whether DSRC records can be found in its central system and provides them to the SP. Information and data exchange is done via organizational means (email, telephone)
F1 DSRC Not used
F2 GNSS
I DSRC Not used
PL DSRC Not used
E DSRC Not used
A/DK DSRC Not used
Table 52. Report DSRC Data records
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 98 of 105
7.4 Example of form for compliance tests As a further contribution for the liaison between WP4 and WP2, the following are to be considered as only reflections about test procedures both in the conformity phase and suitability for use 7.4.1 Organization of back office tests A possible organization of back office tests may have a hierarchical structure, whose first level is related to the test user (Toll Charger or ETS Provider), the second is related to the business processes (e.g. Billing Details among the others), the third is related to the behavior type associated with the test case (valid or invalid). In order to produce the list for each of the two possible “from-to” directions, all the used business processes shall have to be considered, detailing each function produced with reference to the message transmission and reception by the related user. On one hand, tests related to the transmission will check that: i. the user is able to send a data message (spontaneously or by request); ii. this message has valid protocol and format; iii. these tests are then associated to a valid behavior. On the other hand, test related to the reception check that: i. the receiving user reacts to the reception of a data message. ii. this data message is valid or invalid, iii. both the situations are considered, associated to a valid or invalid behavior. As the number of tests in this second case could be huge if all the possible messages are considered, a subset of all the possible messages could be taken into account, by making reasonable and agreed assumptions. The following is only a draft idea for the realization of possible templates to be used in the Suitability for Use tests, performed jointly by the TCs and SPs and related to the correct verification of the chosen back office business processes. As generally described in bullet 8 of the Executive Summary, a multiple level test phase involves different scenarios and consequent verifications of the correct transmission/reception of a data flow. Currently, there are no compliance standard tests for the business processes involving the exchange of information using back office interfaces. As previously said, the following template is to be considered only as an idea how respective tests could be documented and could be used to give input to a possible future CEN group.
D4.1 Definition of Back Office interfaces and of preliminary tests.doc Page 99 of 105
Test form: Business Process
OPERATION Name of Business Process
SCENARIO: Test exchange of flows from Sender to Receiver: timescale
SCOPE OF TEST: TEST RESULT 1. Verification of correct management of application flow generated, comprehending all the cases of correct or incorrect flow and the timescale OK KO case for the good operation, with adequate return flow response.
Possible phases of the test: A. Reception of flow in the systems (specification of the responsibility of OK/KO) by means of a notice or by internal information systems) B. Verification of the flow Acknowledge following the flow (specification of the responsibility of OK/KO).
Notes:
Signatures Sender: Receiver:
7.4.2 Interconnected toll domains As an additional relevant information, interconnected tolling systems (as the DSRC based Italian network) might deserve further attention in the Suitability for Use test phase, due to the peculiar TC-SP-User data exchange model. As a mere example, in the interconnected Italian network more than 20 different Toll Chargers share an interconnected Toll Domain. This means that a user may enter the motorway in a station belonging to Toll Charger 1 and exit the motorway by the exit belonging to the Toll Charger 2 passing through competences of other Toll Chargers. The management of interconnected tolling systems generally is regulated by an agreement on contractual, financial, legal and technical aspects signed by the interested Toll Charger that forms the basis of the contract with possible SPs. Suitability for Use tests will then have to take into account that the “origin” of a message (data acquired in lane) can take place in TC1 competence (entry station) while the elaboration of back office procedures may be done by TC2 (competent for the exit station).
7.5 Terms and definitions
Term / EN ISO 12855 Abbreviation Description Interface Abstraction of the behavior of an object that consists of a subset of the interactions of that object together with a set of constraints on when they may occur Process Action between TCs and SPs comprehending communication messages for data exchange
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 100 of 105
Term / EN ISO 12855 Abbreviation Description Message Set of application data units exchanged by the interested parts Application Data Unit ADU Detail of message between TCs and SPs Billing detail for a given transport service, all necessary data required to determine and/or verify the amount due for the service user Charge report data structure transmitted from the front end to the Back End to report road usage data and supplementary related information Charging data toll relevant data produced by the on-board equipment and sent to the Electronic Toll Service Provider's back-office systems Context data information defined by the responsible Toll Charger necessary to establish the toll due for circulating a vehicle on a particular toll domain and to conclude the toll transaction Enforcement process of compelling observance of a law, regulation, etc Interoperability ability of systems to provide services to, and accept services from, other systems and to use the services so exchanged to enable them to operate effectively together Payment claim recurring statement referring to concluded billing details made available to the Electronic Toll Service Provider by the Toll Charger who indicated and justified the amount due Toll declaration statement to a Toll Charger that confirms the presence of a vehicle in a toll domain in a format agreed between the Electronic Toll Service Provider and the Toll Charger Toll domain area or part of a road network where a toll regime is applied
Toll point location within a toll domain where the on-board equipment has to issue a toll declaration Tolled object distinguished part of a toll domain for which one or more tariff schemata apply Trust object information object that is exchanged between entities to ensure mutual trust
7.6 Other Abbreviations
Abbreviation Description APCI Application Protocol Control Information ASN.1 Abstract Syntax Notation One EFC Electronic Fee Collection FTP File Transfer Protocol XER XML Encoding Rules XML eXtensible Markup Language
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 101 of 105
7.7 Glossary
No. Terminus Abbrev. (short) description
1 Service Provider SP Company / Entity offering the services of an EETS-Provider but not necessarily formally registered as an EETS-Provider.
Since the REETS Project shall facilitate the transition to EETS, it is recommended, to generally use "Service Provider (SP)", except if "EETS-Provider shall be explicitly addressed (e.g. in the context of registration).
2 EETS-Provider EP A legal entity fulfilling the requirements of Art 3 and registered in a Member State where it is
established, which grants access to EETS to an EETS user (see Art 2 b) Decision 2009/750/EC).
3 Member State MS EU Member State
4 European Electronic EETS The abbreviation EETS stands for European Toll Service Electronic Toll Service. It is a service that
enables the payment of tolls with a single contract at a single EETS provider and just one on-board unit throughout the European Union.
5 Regional European REETS The REETS-TEN project aims at deploying Electronic Toll Service EETS compliant services in a cross-border
regional project. The Project shall cover the electronically toll network of 7 Member States (Austria, Denmark, France, Germany, Italy, Poland and Spain) and Switzerland.
6 Toll Charger TC Public or private organisation which levies tolls for the circulation of vehicles in a toll domain
(see Art 2 k) Decision 2009/750/EC)
7 User Physical or legal person who subscribes a contract with a Service Provider in order to have access to EETS compliant services (see Art 2 c) Decision 2009/750/EC).
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 102 of 105
No. Terminus Abbrev. (short) description
8 On Board Equipment OBE The complete set of hardware and software components required for providing EETS compliant services which is installed in a vehicle in order to collect, store, process and remotely receive/transmit data (see Art 2 e) Decision 2009/750/EC)
9 Interoperability Any elementary component, group of constituents 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, see Article 2 of the EETS Decision. Examples of interoperability constituents are on-board equipment (including connected back office systems), roadside equipment (including charging beacons, localization augmentation beacons and enforcement devices), EETS Providers’ and Toll Chargers’ back-office data exchange systems.
10 Toll A charge, tax or duty levied in relation with circulating a vehicle in a toll domain (see Art 2 j) Decision 2009/750/EC)
11 Toll domain An area of EU territory, a part of the European road network or a structure (such as a tunnel, a
bridge, a ferry,..) where toll is collected (see Art 2 n) Decision 2009/750/EC).
12 Tariff class The set of vehicles treated similarly by a Toll Charger (see Art 2 g) Decision 2009/750/EC).
13 Vehicle classification The vehicle related information according to parameters which tolls are calculated based on the Toll Context Data (see Art 2 q) Decision
2009/750/EC).
14 Certification 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.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 103 of 105
No. Terminus Abbrev. (short) description
15 Technical accreditation Technical accreditation covers the technical aspects of the accreditation of an already registered EETS Provider in individual toll domains under responsibility of a Toll Charger (or a cluster of Toll Chargers).
16 Technical requirements Requirements defined by the Member State for registration responsible for the registration to check against Article 3b of the EETS decision
17 Toll domain Technical specifications for interoperability independent constituents that are defined by technical specifications standards or other regulations or specifications independently from individual toll domain requirements
18 Toll domain specific Technical specifications for interoperability specifications constituents that comprise requirements that are specific to the needs of a toll domain
19 Security Policy A Security Policy is a set of requirements and applicable counter measures specified by the
party responsible for the security in a system exposed to threats. These counter measures are based upon a risk analysis of the system in order to protect those data exposed to threats in the relationships between TC and SP.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 104 of 105
No. Terminus Abbrev. (short) description
A cluster of ETC Toll Domains is a set of Toll 20 Cluster Domains, interconnected or not, which feature the same or very similar ETC toll collection context(s) in a contractual framework like Memorandum Of Understanding or any other agreement between the Toll Domain representatives, i.e. the Toll Chargers. This agreement specifies the rules regarding interoperability and its management within that cluster of ETS Toll Domains; it includes references to mutually agreed and shared detailed contractual, procedural and operational documentation as well functional and technical specifications (particularly, interfaces for OBU // RSE and for Toll Charger // Service Provider central systems). A cluster of Toll Domains may have a unique representative for some common subjects. Relationship between Toll Domains and Service Providers are fixed by bilateral contracts. Common validity periods of bilateral contracts with a given ETC Provider allow the interoperability for the global cluster.
21 Accreditation The Accreditation covers the whole procedure (contractual and technical) to be successfully fulfilled by a Service Provider in order that its technical system could be accepted on a Toll Domain and that the TC entrusts the SP with the toll collection and the invoicing process to the SU.
When the Accreditation is successfully completed, the Service Provider is “accredited” in the relevant Toll Domain.
REETS TEN_D4 1_Definition_of_Backoffice_interfaces_v2_2014-07-16.doc Page 105 of 105