Participants BoardFlensburg, 20 September 2011

Herman Grooters (RDW / NL) Project Manager EUCARIS

EUCARISDevelopments

ERRU, RESPER, CoC

EUCARISERRU

ERRU: European Registration of Road transport Undertakings Exchange based on Regulation (EC) No 1071/2009 and 1213/2010

– Infringements – Member States communicate information on infringements committed by operators (+ sanctions) to the Member State which issued their licence

– Good repute - Member States consult relevant information held by all other States to assist them in deciding whether or not to issue or renew an operator’s licence.

Messages Infringement notification Infringement response Search request regarding the fitness of transport manager Search response

ERRU – Introduction

EUCARIS ERRU central system

Member State

Member State Member State

Member State

Central hub

ERRU – System architecture

EC requires weekly statistics on information exchange Statistics must include figures on availability and performance Especially information on penalties resulting from notifications of

infringements abroad is interesting (notification response)

EUCARIS has to:– Calculate its own statistics per MS– Consolidate these (anonym) statistics at the secretary state in a weekly ‘report’– Communicate this weekly report to the central system via a specific message

Consequences for EUCARIS:– Adaptation of the logging (inclusion of performance figures, relation between

asynchronous request and response message)– Development of a new service to communicate the weekly statistics with the EC

ERRU – Additional work

16-12-2010: Publication of Regulation 1213/2010 on interconnection From April 2011: development broker July 2011: ERRU technical documentation finalised From September 2011: development of EUCARIS ERRU services 04-12-2011: Regulation 1071/2009 will enter into force

National Registers set up; public access organisedNCPs appointedNational legal measures communicated with EC

January 2012: start of deployment EUCARIS ERRU services (release 7.0) From June 2012: tests EUCARIS MS with central hub 31-12-2012: Interconnection of registers 01-01-2013: Start of check good repute by using ERRU

ERRU – Time schedule

EUCARISRESPER

Resper - Introduction

Legal framework: Third Driving Licence Directive (2006/126/EC) Aims: a.o. stimulation of cross-border exchange of information by

realisation of a European network (Resper) Main goal: to prevent the issue of a DL to an applicant who already has a

valid EU Driving Licence Approach: Check via a search by name and date of birth in case there are

reasonable grounds to suspect that the applicant already holds a DL formerly issued in another EU State;

The EC in co-operation with an Expert Group of representatives from the MS has prepared a questionnaire to solve a series of problems:

First issue: ‘reasonable grounds’– In what situations will MS check in the other countries? Consequently: what

load (number of inquiries) may we expect?

Outcome: the interpretation of ‘reasonable grounds’ is up to the Member States; NL: applicants who lived outside NL preceding the application; professional drivers; people with an ended sanction (5% of the cases)

Expected load: uncertain; EC investigated several scenarios; a peak load of 2 inquiries per second in each state is expected;

EC requires that EUCARIS can deal with up to 25 million inquiries in each MS yearly;

Results of further studies

Second issue: the system architecture: – The EC has indicated to accept the use of EUCARIS. States will have a free

choice between EUCARIS and access via a central hub (TACHOnet-like architecture).

– EUCARIS and RESPER will be linked by a broker; we will use the same solution as in ERRU

– EC has indicated not to install any Central Index

Resper – Architecture

EUCARIS – TACHOnet Integrated Architecture High level connection of ‘distributed bus’ and ‘hub and spoke’ models

EUCARIS TACHOnet

Member State

Member State Member State

Member State

Central hub

Third issue: search by name – EC has indicated that probably a phonetic search algorithm will be used

No final proposal yet!– This algorithm will be mandatory for all– Basic idea:

Suppose a country searches for mrs. BlomThen first we calculate a key; e.g. the Phonex key, mainly based on the consonants in the name => B4500

Result of the search through Europe could be:• From Sweden: mrs. Bløm => OK, only the diacritical character is

different; further investigation necessary• From Italy: mrs. Paolini => quite different, but the same Phonex key! • From NL: we would not get mrs. Blom e/v Jansen (key = B4512) although

this is actually the same person, but married meanwhile

– Conclusion: we will miss hits (false negatives) but also get false positives causing a lot of manual work

Resper – Search by name

Proposal: we need a ‘filter’ mechanism indicating the probability that a requested person and a provided person are the same. Example:– Request: Blom; Maria; female; 10-05-1954; Rotterdam; id = 12ab34cd56ef– Sweden: Bløm; Maria; female; 10-05-1954; ?; ? => 96%– Italy: Paolini; Maria; female; 10-05-1954; Rotterdam; ? => 27%

Conclusion: the requesting process will decide based on the calculated probability how to process the results:– A DL issuing process might work with a short list and skip all hits

with probability < 95%;consequently this process will automatically skip Paolini and select Bløm for further investigations in a manual procedure (e.g. extra info by email)

– A police search might always process the long list and examine all candidates by manual procedure;consequently this process will examine both Paolini and Bløm

Resper – filtering

EUCARIS

Member States

EUCARIS

Requestingprocess

Providingprocess

DL Index

DL Reg

RESPER filter module

Key ; MCI

Filter Filter

Addition of probability

1-10-2011: RESPER interface (message specifications) and Network and Security Reference Guide available (delivered by Siemens)

November 2011: EUCARIS documentation available January 2012 - May 2012: development of the RESPER services within the

EUCARIS application; June 2012: start of implementation of the EUCARIS interface in the MS October 2011 - June 2012: system adaptations and implementation in the

Member States July - December 2012: Testing with the Central Hub 19-01-2013: RESPER operational

RESPER time schedule

EUCARISCoC

17

CoC; Summary European legislation (a.o. Directive 2007/46/EC)

European Directives and interpretative communications– Registration is based on the valid CoC – Manufacturers are obliged to deliver a CoC with the vehicle– The manufacturer may deliver the CoC info to the Registration Authority via

electronic means

– Member States are only allowed to register a vehicle if a valid CoC is present– The CoC should be sufficient to admit the vehicle and to issue a Vehicle

Licence– Refusal of a CoC is not allowed unless….– New vehicles with a type approval have to be registered based on the valid

CoC; MS may not refuse this.

18

Vehicle Registration

Information

Registration process

Present, valid?

Type Approvals

CoCs

MS Vehicle

Reg.

Manufacturer

Manufacturer

Internet

EUCARIS

Other CoC databases

Manufacturer

Manufacturer

19

Open issues

Concept:– Based on market: logically: 1 CoC database per MS; technically: joint

effort: some MS might use a common database – Based on manufacturers: each manufacturer has 1 database for the

entire EU– Based on TA Authority: each manufacturer has 1 or several databases,

depending on the TAA Communication

– Manufacturers => CoC database via internet – Communication between EU MS no problem => new EUCARIS services– If several ‘central’ CoC databases are created (+ CoC registers at some

manufacturers) should EUCARIS deal with addressing the right database?

– Or do we perform a MCI (broadcasting), checking at different places– Or do we forward a CoC meant for another country to the CoC database

in that country

20

Current status

Cooperation:– EReg participants have gathered in June 2011 on this topic– At least eight countries are very much interested in a joint development of a

series of distributed CoC databases– EReg is now asked to install a new topic-group or a subgroup in one of the

existing TGs– We will cooperate with the TAAM (association of Type Approval Authories)

Approach:– Definition of a harmonized CoC XML message; status: first draft almost ready

(proposal by KBA and RDW)– First reactions of manufacturers are positive– EC will be informed and involved; possibly we will ask for adaptation of the

legislation; we start on voluntary basis Time schedule:

– Next meeting: beginning of November– Developments EUCARIS next year

EUCARISOther developments

Mileage:– Waiting for development of a national network in Belgium linking DIV and Carpass– Legal framework not decided yet– Luxembourg possibly interested

PTI:– On hold; waiting for development of a decentralised Vehicle Platform in relation to

CoC– Could become an extension of the planned exchange of vehicle data (CoC) from

manufacturers to RAs, at first registration– No meetings with FSD yet

Crossborder exchange of O/H for the collection of parking fines:– Possibly based on @@@@/EC; legal possibilities investigated

VIN-cube– In development; able to read VINs from all electronic systems of vehicles (e.g.

airbags); – it can be checked with the regular EUCARIS vehicle Inquiry by VIN whether one of

the systems originates from a stolen vehicle

Other developments