REPORT N. ERA-REP-100
OF THE EUROPEAN RAILWAY AGENCY
ON
the possible inclusion in ERATV of types of vehicles that were
authorised before 19 July 2010
Disclaimer:
The present document is a non-legally binding report of the European Railway Agency. It does not
represent the view of other EU institutions and bodies, and is without prejudice to the decisionmaking processes foreseen by the applicable EU legislation. Furthermore, a binding interpretation
of EU law is the sole competence of the Court of Justice of the European Union.
European Railway Agency – 120 rue Marc Lefrancq – BP 20392 - 59307 Valenciennes Cedex, France
Tél : +33 (3) 27 09 65 00 – Fax : +33 (3) 27 33 40 65
www.era.europa.eu
REPORT N. ERA-REP-100
Table of Contents
0.
Executive summary .......................................................................... 3
1.
Introduction ..................................................................................... 6
2.
Workgroups ..................................................................................... 6
3.
Working methods ............................................................................ 6
4.
Scope of the analysis ........................................................................ 7
4.1.
4.2.
4.3.
5.
Registration of existing vehicles types in ERATV ............................. 10
5.1.
5.2.
5.3.
5.4.
6.
Clarifications about existing vehicles ....................................... 7
Definition of existing vehicles types ......................................... 8
Population of existing vehicles ................................................. 9
Voluntary registration ............................................................ 10
Amendments to ERATV Specification .................................... 11
Changes in the application User Interface ............................. 14
Interface ERATV-ECVVR .......................................................... 14
Impact assessment ......................................................................... 15
6.1.
6.2.
6.3.
6.4.
Introduction ............................................................................ 15
Methodology .......................................................................... 15
Key Findings ............................................................................ 16
Conclusions of the impact assessment .................................. 16
7.
Relationship with Study on Registers .............................................. 16
8.
Conclusions .................................................................................... 16
Annex 1: Definitions and abbreviations .................................................................... 18
Annex 2: Reference documents ................................................................................ 20
Annex 3: Reference legislation .................................................................................. 21
Annex 4: Impact Assessment Report ......................................................................... 23
Page 2 of 23
REPORT N. ERA-REP-100
0.
Executive summary
Note
This report has been prepared by the Interoperability Unit of ERA. It has
been discussed with the ERATV WP. Formal comments received from the
WP members will be included in an Annex.
Legal context
Vehicle type is defined in Article 2(w) of the Interoperability Directive as
“the basic design characteristics of the vehicle as covered by a single type
examination certificate described in module B of Decision 93/465/EEC”. The
same Directive in Article 34 established the European Register of
Authorised Types of Vehicles (ERATV). Vehicle types authorised according
to Article 26 must be registered in ERATV. The definition provided by
Article 2(w) is strictly related to the modules for verification of conformity.
The ERATV Decision sets the Specification of ERATV, including the data to
be provided and the rules for data input and modification; additionally in
Article 5(2) it mandates the Agency to investigate “[…] the possible
inclusion in the register of types of vehicles that were authorised before 19
July 2010”.
Scope of the
analysis
It is not always possible to establish a correspondence between a vehicle
and a vehicle type that is authorised in accordance with Article 26 of the
Interoperability Directive. Nevertheless, it should be remarked that, the
concept of type existed before being formalized in the EU legislation (first
for generic products and then specified for the railway sector) and was
well known by railway vehicles manufacturers and railway undertakings.
On the other hand the possibility to include the types (i.e. all relevant
technical characteristics) of all vehicles in service into one single register
(e.g. ERATV) might be beneficial for the railway system.
For the sake of convenience, vehicles that were authorised for placing in
service before 19 July 2010 whose authorisations for placing in service are
valid according to Article 21(12) of Directive 2008/57/EC are referred to in
this Report as existing vehicles.
Therefore, for the purpose of the investigation mandated by Article 5(2) of
the ERATV Decision the main question to be answered is:
Would the inclusion in ERATV of existing vehicles types be beneficial for
the railway system?
In other words, would it contribute to make the railway system work
better for society?
Before addressing the main question above, two preliminary questions
need to be answered:
Page 3 of 23
REPORT N. ERA-REP-100
a) Is it possible to find a definition of existing vehicles type?
b) Can the existing vehicles types be registered in ERATV?
Main findings
1. Definition of A definition of type for existing vehicles can be given by analogy to the
type for
definition of vehicle type provided in Article 2(w) of the Interoperability
existing vehicles Directive.
An existing vehicles type means a vehicle type defining the basic design
characteristics of the vehicle, as evinced by supportive technical
documentation.
The other way around, two existing vehicles belong to the same type if
they share the same basic design characteristics as evinced by supportive
documentation such as relevant technical documentation, manufacturing
series, certificates, etc.
Therefore, it can be possible to establish a correspondence between an
existing vehicle and a type.
2. Voluntary
registration
Considering the high number of types involved, in order to not generate
additional administrative burden, it has been agreed that the registration
of existing vehicles types is voluntary.
All the analysis done relies on this assumption.
3. Amendments
to ERATV
Specifications
Existing vehicles types did not go through the type authorization process
according to Article 26 of the Interoperability Directive, therefore most of
the data required by the ERATV Decision might be either not available or
not applicable.
Consequently, the inclusion in ERATV of existing vehicles types requires an
amendment of the ERATV Specification. The amendments of the
Specification to support the inclusions of existing vehicles types are
described in §5.2 Amendments to ERATV Specification and specify:
 the set of data to be provided
 the rules for data input and modification
ERATV software needs to be amended accordingly.
The structure of the vehicle type number does not need to be changed.
In order to avoid confusion, authorised types and existing vehicles types
must be clearly recognizable within the register user interface.
4. Impact
assessment
The impact assessment carried out by the Economic Evaluation Unit of ERA
is in Annex 4: Impact Assessment Report.
Page 4 of 23
REPORT N. ERA-REP-100
The main stakeholders have been interviewed to assess costs and benefits
of the voluntary registration of existing vehicles types in ERATV.
The interviews showed that, besides a wide variety of views, no
stakeholder formulated any clear, quantifiable benefit of such voluntary
registration.
Furthermore, the evaluation of the main reported benefits - simplification
of preliminary compatibility checks, facilitation of cross-acceptance
(granting of additional authorisations) of vehicles and fleet statistics-,
depends on the clarification of the purpose of vehicle related registers
kept by Institutions, expected to specify the role of the registers in
processes such as checking technical compatibility with infrastructure or
granting authorizations.
5. Relationship
with Study on
Registers
The activities carried out within the Study on Coherence and Consistency
of Registers [III] made clear that the following approach is generally agreed
by all stakeholders: besides barely answering specific needs, any further
evolution of registers should try to preserve or enhance the consistency
and effectiveness of the system of registers kept by Institutions, while
preserving the intended purpose of each register.
It is recommended that the possible inclusion of existing vehicles types in
ERATV follows this approach.
As follow-up to the Study on Coherence and Consistency of Registers [III]
the Agency will establish a Working Party on the Rationalisation of the
Vehicle Related Registers (ERATV, ECVVR, VKMR, register of certified
ECMs) that will commence its works in September 2013.
Conclusions
The impact assessment showed that the benefits of voluntary registration
of existing vehicles types in ERATV are not evident or cannot be exactly
quantified independently from the rationalisation of vehicle related
registers.
In other words, no decisive elements have been found that recommend
the immediate amendment of ERATV Specification for the inclusion in
ERATV of existing vehicles types.
The main findings of this Report will be used as input for the Working Party
on the Rationalisation of the Vehicle Related Registers.
Page 5 of 23
REPORT N. ERA-REP-100
1.
Introduction
Article 5(2) of ERATV Decision mandates the Agency to “[…] submit a recommendation to the
Commission on the possible inclusion in the register of types of vehicles that were authorised
before 19 July 2010 and on the possible amendment of this Decision based on the experience
gained not later than 18 months after the entry into force of this Decision”.
For the sake of convenience these vehicles - i.e. vehicles authorised for placing in service before
19 July 2010, whose authorisations for placing in service are valid according to Article 21(12) of
Directive 2008/57/EC (see §4.2 Definition of existing vehicles types) - have been called existing
vehicles, and the types corresponding to existing vehicles are referred to as existing vehicles
types.
This report presents the conclusions of the ERA on this subject.
2.
Workgroups
This report has been prepared by the Interoperability Unit of ERA in collaboration with the
representative bodies from the railway sector and NSAs, in the framework of the working party
established for drafting and maintaining the ERATV Specification.
Following representative bodies have participated in it: CER, UNIFE, UIP and UITP.
NSAs of several MSs have participated in the working party as well: Belgium, Denmark, Finland,
France, Germany, Greece, Italy, Luxemburg, Norway, Portugal, Romania, Slovakia, Spain,
Sweden and the United Kingdom.
3.
Working methods
The applied methodology consisted of the following steps:
i.
ii.
iii.
Definition of the scope of the analysis:

Clarifications about existing vehicles.

Definition of existing vehicles types.

Voluntary versus mandatory registration.
Registration of existing vehicles types in ERATV

Investigation of the minimum set of technical data generally available for
existing vehicles.

Description of workflows for registration of existing vehicles type in ERATV
(actors, roles, actions, information flows, etc.).
Definition of amendments to the ERATV Specification (see §5.2 Amendments to ERATV
Specification) to support existing vehicles types:
Page 6 of 23
REPORT N. ERA-REP-100

general principles

set of mandatory data

rules for data input and modification

numbering

definition of additional requirements for the management of existing vehicles
types (e.g. user interface).
iv.
Impact Assessment (see Annex 4: Impact Assessment Report).
v.
Analysis of coherence with the “system” approach to rationalisation of vehicle related
registers.
vi.
Conclusions.
4.
Scope of the analysis
4.1.
Clarifications about existing vehicles
The Interoperability Directive gives legal definitions for both “Vehicle” and “Type” in Article 2:
Article 2(c) states that “vehicle means a railway vehicle that runs on its own wheels on railway
lines, with or without traction. A vehicle is composed of one or more structural and functional
subsystems or parts of such subsystems”.
Article 2(w) states that “type means a vehicle type defining the basic design characteristics of the
vehicle as covered by a single type examination certificate described in module B of Decision
93/465/EEC”.
In addition, the Interoperability Directive, “with a view to facilitating the placing in service of
vehicles and reducing administrative burdens“, introduced the concept of authorised type of
vehicle that is a vehicle type authorized pursuant to Article 26.
The Agency, as per Article 5(2) of ERATV Decision, is in charge of investigating the possibility of
inclusion in ERATV of “types of vehicles that were authorised before 19 July 2010”.
Therefore, does the word “authorized” in Article 5(2) mean authorized according to any of the
regimes existing before 19 July 2010 (in the sense of art 21(12) of Interoperability Directive)?
Additionally does the word “authorized” in Article 5(2) refer to the word “types” or to the word
“vehicles”?
It has been understood by the Working Party that Article 5(2) uses the word “authorised” in the
meaning of Article 21(12) of Interoperability Directive and that the adjective “authorized” refers
to “vehicles”; in other words, the scope of the investigation are vehicles that were placed in
service before 19 July 2010, whose authorisations for placing in service are valid according to
Page 7 of 23
REPORT N. ERA-REP-100
Article 21(12) of Directive 2008/57/EC, that do not fall into any of the cases already described in
Annex I (1.) of the ERATV Decision.
This understanding is supported by the following considerations:
• the Article 5(2) cannot request ERA to investigate about the possible inclusion in ERATV of
types that are already foreseen to be in the register according to the same Decision (the
case of “Types of vehicle authorised before 19 July 2010“ is already foreseen in Annex I (1.)
of ERATV Decision). Additionally the wording in the Agency recommendation on ERATV
specification [II], at point 8., reads: “The Agency should evaluate the possibility of using the
ERATV application for the existing vehicles”
 “authorised” referred to vehicles must be intended as placed in service under any of the
regimes existing before the Interoperability Directive and therefore in the meaning of
Article 21(12).
4.2.
Definition of existing vehicles types
The European legislation provides definitions for railway vehicle type through:
 The Interoperability Directive in the already mentioned Article 2(w);
 Decision 2010/713/EU1 [7] where a type is defined as “[…] a specimen, representative of the
production envisaged […], …manufactured in conformity with the technical documentation’
The technical documentation2 shall make it possible to assess the subsystem’s conformity
with the requirements of the relevant TSI(s)” and inter alia “shall contain[…]documents
necessary for the compilation of the technical file as described in point 4 of Annex VI to
Directive 2008/57/EC”. Additionally, “the certificate and its annexes shall contain all
relevant information to allow the conformity of manufactured subsystems with the
examined type to be evaluated.”
In other terms, the definition of type given in Article 2(w) is strictly linked to modules for
verification of conformity and the results of the EC-type examination procedure, that is a EC-type
examination certificate (or better, a set of EC-type examination certificates, one for each
subsystem composing the vehicle type, see [I] and [IV] for more details) and the attached
documentation (annexes and additions to the EC-type examination certificate together with the
technical documentation).
Existing vehicles types did not undergo any EC-type examination procedure and therefore are
missing the corresponding documental results.
1
Decision 2010/713/EU defines the conformity assessment modules specific for railways and their
correlation in generic modules defined in Decision 768/2008/EC.
2
Submitted by the applicant for EC-type examination certificate
Page 8 of 23
REPORT N. ERA-REP-100
Nevertheless, it should be remarked that, the concept of type existed before being formalized in
the EU legislation (first for generic products3 and then specified4 for the railway sector) and was
well known by railway vehicles manufacturers and railway undertakings.
It is evident that not all vehicles in service are different: manufacturers built series of identical
vehicles, railway companies carried out identical modernisations/upgrading to vehicles of the
same series, etc.
In some cases, the authorisation for placing in service were issued for series of vehicles and
included principles similar to “type authorisation”, even though different wordings were used, e.g.
“homologation” or “certification”.
Therefore, NSAs and/or manufacturers and/or railway undertakings and/or vehicle keepers
should be able to identify the types that correspond to existing vehicles.
In conclusion, a definition of type for existing vehicles can be given by analogy to the definition of
vehicle type provided in Article 2(w) of the Interoperability Directive:
An existing vehicles type means a vehicle type defining the basic design characteristics of the
vehicle, as evinced by supportive technical documentation.
The other way around, two existing vehicles belong to the same type if they share the same basic
design characteristics as evinced by supportive documentation such as relevant technical
documentation, manufacturing series, certificates, etc.
Given the definitions above, it seems possible to establish a correspondence between an existing
vehicle and a type. In other words the Registration Holder (RH) of an existing vehicle in a NVR
should be able to indicate the type of such a vehicle on the basis of the information already
available to him.
4.3.
Population of existing vehicles
It has been discussed the need of criteria for limiting the cardinality of the population of existing
vehicles based on, for example:
 date: e.g. only existing vehicles placed in service after a certain date, for example after 1
Jan 1995
 use: e.g. existing vehicles used in international traffic
 category of vehicle: e.g. only traction vehicles and freight wagons etc.
However the ERATV WP members have not expressed the need for having any of these
constraints considering that:
3
4
Decision 93/465/EEC, repealed by Decision 768/2008/EC.
Directive 2008/57/EC and Decision 2010/713/EU
Page 9 of 23
REPORT N. ERA-REP-100
 Article 33(2) of the Interoperability Directive states that “For each vehicle the national
vehicle register shall contain…”, inter alia, “…the reference to ERATV.” It is therefore
pertinent to make possible the registration in ERATV of existing vehicles types.
 due to the likely high number of existing vehicles types involved, in order to not generate
excessive administrative burden, it has been agreed that the registration of existing vehicles
types is to be carried out on voluntary basis (see §5.1 Voluntary registration).
All the analysis done in this Report relies on the assumption of the voluntary registration of
existing vehicles types.
5.
Registration of existing vehicles types in ERATV
5.1.
Voluntary registration
Considering the high number of vehicles involved, in order to not generate excessive
administrative burden for the actors involved (RH, NSA, Agency) in the registration process it has
been agreed that the registration of existing vehicles types in ERATV is voluntary and it is carried
out following the request from the vehicle Registration Holder.
All the analysis done in this Report relies on the assumption above.
With this assumption, the vehicle Registration Holder will apply for the registration of an existing
vehicles type into ERATV (see also §5.2.2 Rules for data input and modification) if deemed
advantageous from a business perspective.
Nevertheless, a right placed on the side of the Registration Holder induces an obligation for the
NSA and the Agency to follow up with the registration request with tasks such as:





the input of data
the validation of the submitted data against the Specification
the check for duplicates (types already registered in ERATV)
the assignment of the unique identifier of the type (vehicle type number)
(if the NSA is also acting as RE) the update of the NVR records (vehicles registered in NVR
and belonging to the given type) by adding the ERATV reference.
The costs and benefits associated to the voluntary registration for the railway system as a whole
are examined in details in §6 Impact assessment.
The detailed workflow regarding existing vehicles type registration and the responsibilities of the
actors involved (RH, NSA, Agency) have been discussed and agreed and are described in §5.2
Amendments to ERATV Specification.
Besides the voluntariness of the registration, other measures have been taken into account in
draft amended ERATV Specification to keep control on the costs deriving from the obligation to
follow up with the registration requests by the Registration Holder (see §5.2.1 Extension of data).
Page 10 of 23
REPORT N. ERA-REP-100
5.2.
Amendments to ERATV Specification
5.2.1.
Extension of data
The existing vehicles did not go through the type authorisation process according to Article 26 of
the Interoperability Directive (nor the EC verification procedure nor the EC-type examination
procedure), therefore most of the data required by the ERATV Decision might be either not
available (i.e. not verified) or not applicable.
Consequently, the extension of the ERATV scope to existing vehicles types requires an
amendment of the ERATV Specification in order to specify the set of data (mandatory and
optional parameters) to be recorded in ERATV for existing vehicles types.
The criteria used to identify such set of data have been as follows:
i.
Parameters in Section 0 “Identification of the type” and Section 1 “General Information”
of table in ANNEX II of ERATV Decision remain unchanged.
ii.
Parameters in Section 2 “Conformity to TSI” are all left as optional.
iii.
Parameters in Section 3 “Authorisations” are all left as optional and might be populated to
record any authorisation of type granted to the existing vehicles types under the
Interoperability Directives before Directive 2008/57/EC.
iv.
Out of the list of ERATV technical parameters (Section 4 “Technical characteristics of the
vehicle” in ANNEX II of ERATV Decision) it has been identified the subset of mandatory
technical parameters that are certainly available for existing vehicles for being necessary
in normal operations; the so identified subset, roughly 25% of technical parameters, will
be mandatory for existing vehicles types as well.
v.
A supplementary Section 3a “Authorisations under regimes existing before Directive
2008/57/EC” has been introduced including parameters:



3a.1
3a.2
3a.3
Member State where vehicles of this type were placed in service
Agreements the type is in conformity with
Comments
These parameters account for the international agreements (e.g. RIV, RIC, PPV/PPW) the
type is in conformity with, the Member State(s) where vehicles of the type were placed in
service, additional details on who authorised it and when (e.g. the former integrated
railway company in 19XX) and rules which were used for verification.
The fact that the ERATV record belongs to existing vehicles types or to a vehicle type authorised
according to Article 26 of the Interoperability Directive will be made clear by means of:
 Special arrangements in the User Interface (see §5.3 Changes in the application User
Interface)
 The format of the vehicle type number (see §5.2.3 Numbering)
Therefore no additional parameter needs to be added to Section 0 Identification of the type to
achieve the above objective.
Page 11 of 23
REPORT N. ERA-REP-100
It has been discussed the case where the vehicle is registered (by the same Registration Holder) in
the NVR of more than one Member States and the possibility, for Registration Holder, to supply in
parameter 3a.1 the list of such Member States. As this option is mainly related to the software
implementation it has been reckoned irrelevant from the perspective of the draft amended
ERATV Specification.
5.2.2.
Rules for data input and modification
Pre-requisite for the registration of an existing vehicles type in ERATV is that vehicles of that type
are registered in a NVR.
It has been agreed that the registration of a type corresponding to an existing vehicle shall be
carried out according either of two modalities:
i.
Upon request from the vehicle Registration Holder.
The Registration Holder of the vehicle submits a request to the NSA of the Member State
where the vehicle is registered in the NVR. The request shall include the data as identified
in §5.2.1 Extension of data. The NSA shall transmit the request to the Agency for validation
against the Specification and publication.
ii.
Upon invitation from the NSA to the vehicle Registration Holder.
The NSA of a Member State where a vehicle is registered in the NVR, on the basis of data
available to it, may propose to the Registration Holder the registration of the corresponding
type in ERATV. The Registration Holder may accept to proceed with the registration and
verify/complement the data, or refuse the registration. In the first case, once the data have
been verified/ complemented by the Registration Holder, the NSA shall submit the request
to the Agency. The request shall include the data as set out in §5.2.1 Extension of data.
In either of the cases above the Registration Holder is solely responsible for the correctness of the
data provided for the registration.
Nevertheless, the NSA may decide to assist the Registration Holder in the correct application of
the Specification and the correct designation of the type, in order to facilitate the registration,
prevent the submission of duplicated types and avoid duplicated administrative burden, in the
collaborative spirit of Article 26(6) of Interoperability Directive.
The Agency shall checks the submitted data against the draft amended ERATV Specification and
either validate it and assign a vehicle type number or request its correction or clarification to the
NSA either validates it or requests its correction or clarification. The NSA, in turn, shall contact the
Registration Holder for providing such correction/clarification.
Additionally the Agency shall check, as far as the data available in ERATV allow, that this type has
not been registered before by another Member State.
In order to not generate excessive administrative burden and give consideration to the limitations
in terms of resources of the NSAs and the Agency, it has been agreed that no time constraints are
to be set for the validation of the requests by the Agency or the transmission of the requests from
the NSAs to the Agency.
Page 12 of 23
REPORT N. ERA-REP-100
Similarly, no time constraint is set for the Registration Holder to reply to requests of
correction/clarification raised by the NSA or the Agency.
In order to contain the administrative burden for NSAs, it has been discussed the possibility for
the Registration Holder to directly input the registration data in ERATV and after that forward the
request electronically to the relevant NSA. As this option is mainly related to the software
implementation, it has been reckoned irrelevant from the perspective of the draft amended
ERATV Specification.
Besides the first submission of data for an existing vehicles type, the Registration Holder will be
allowed to:
 submit additional data for the registered type, in the cases whether these data are
voluntary and were not provided when the type was registered,
 submit data related to the correction of an error
5.2.3.
Numbering
Although the possibility to use specific identifiers for existing vehicles types has been considered,
finally it has been agreed to keep the format of the vehicle type number described in ANNEX III of
ERATV Decision:
XX
XXX
XXXX
X
Category
Subcategory
Family
(Platform)
Incremental
number
Check digit
Field 1
Field 2
Field 3
Field 4
The only potential issue linked to the choice above is related to the consumption of the
numbering resources: 3 digits allocated within the vehicle type number to the Family (Platform)
mean a maximum of 999 distinct platforms per subcategory of vehicle. Considering the cardinality
of the population of existing vehicles, there is a risk that all the available values for Field 2 would
get consumed by existing vehicle types.
Considering the potential issue above and, on the other hand, the wish to make it easier for public
user the distinction of an existing vehicles type within the register, it has been agreed that for
each Subcategory, digits in Field 2 Family (Platform) from 900 onwards are reserved to existing
vehicle types.
Therefore, an existing vehicles type will be assigned a vehicle number XX-9XX-XXX-X and would be
immediately recognizable.
Besides the choice above, other arrangements in the User Interface (see §5.3 Changes in the
application User Interface) have been also agreed to further mark the separation between
existing vehicle types and other types registered in ERATV pursuant the ERATV Decision.
Page 13 of 23
REPORT N. ERA-REP-100
5.3.
Changes in the application User Interface
5.3.1.
Arrangements for the recognisability of existing vehicles types
The ERATV WP members have expressed the requirement of a clear recognisability of existing
vehicles types within the ERATV user interface versus other types registered pursuant the ERATV
Decision.
Besides a specific format of the vehicle type number (see §5.2.3 Numbering) other arrangements
in the user interface have therefore been agreed:
 a separate section of the ERATV application will be used to register existing vehicle type.
Access to this section shall be easy and well characterized in the user interface. A disclaimer
will also be displayed to the user.
 a visual indication should be displayed aside each recorded existing vehicle type (i.e. in the
search results) to easy immediate recognisability.
5.3.2.
Tools for mass upload of data
Considering the cardinality of the population of existing vehicles, it is realistic to expect a high
number of existing vehicles types.
On the other hand, in some cases databases or other legacy systems are available (i.e. to NSAs or
RUs) that contain most of the data necessary for the registration of the type in ERATV, although
the data may be in a different format or distributed among a variety of data sources.
In the hypothesis that such data can be exported to a recognizable exchange format (i.e. csv files,
excel files, txt files, etc.), the input into ERATV would be much facilitated by tools for the mass
upload.
The benefit would be remarkable at the initial point, when the mass of existing vehicles types
could be imported in ERATV, as opposed to the day-to-day maintenance of the ERATV records
(modification/correction of errors). Indeed the ERATV WP Members have agreed that the
availability of such tool is essential for the practical feasibility of the registration of existing
vehicles types in ERATV.
5.4.
Interface ERATV-ECVVR
Following the registration of an existing vehicles type in ERATV, the NVR records corresponding to
vehicles belonging to the type need to be updated by adding the ERATV reference in field 5.
“Reference to the European Register of Authorised Types of Vehicles (ERATV)”.
According to Article 33(3) of Interoperability Directive the Registration Holder “[…] shall
immediately declare any modification to the data entered in the national vehicle register […]”;
therefore, following the registration of an existing vehicles type the Registration Holder shall
supply to the Registration Entity(-ies) the list of NVR records to be updated and the reference to
be recorded in field 5.
Page 14 of 23
REPORT N. ERA-REP-100
Vehicles are to be associated to an existing vehicles type by the Registration Holder on the basis of
supportive documentation, as described in §4.2 Definition of existing vehicles types.
No functionalities (IT links) are currently available to facilitate the mass update of NVR records.
ERATV is a public database, consequently all data concerning the registered (i.e. validated and
published) types is available to public users.
No exception to this approach is envisaged in the case of existing vehicles types. On the other
hand, NVR is not a public database and the access to data is disciplined by Article 3.3. Access
rights of NVR Decision.
Therefore the link between NVR records and the corresponding ERATV record is unidirectional
(from NVR to ERATV).
No exception to this approach is expected as a consequence of the extension of ERATV to existing
vehicles types.
6.
Impact assessment
6.1.
Introduction
An impact assessment has been carried out by the Agency’s Economic Evaluation Unit in order to
assess the main benefits and costs for different categories of stakeholders (e.g. railway
undertakings, keepers, infrastructure managers, rail manufacturers, NoBos, Government, etc.)
due to the extension of scope of ERATV to existing vehicles types.
The full impact assessment Report is in Annex 4: Impact Assessment Report.
6.2.
Methodology
The core part of the impact assessment is a consideration to the costs and benefits generated
relative to the reference scenario (i.e. ERATV specification without amendments). This impact
assessment utilises quantitative and qualitative analyses as available.
In accordance with the Agency’s Economic Evaluation Guidelines, the impact assessment
examines main benefits and costs for different categories of stakeholders (e.g. railway
undertakings, keepers, infrastructure managers, rail manufacturers, NOBOs, Government, etc.)
due to the proposed changes of ERATV.
The key principle of the impact assessment is the comparison of the reference scenario (Donothing or Do-minimum) with one or several project scenarios. This will allow identification of
effects on key aspects that could be caused by change regarding ERATV.
For this impact assessment the following data collection methods have been used in order to
provide the required information to examine the expected consequences:
 Interviews (telephonic, or visits) with selected stakeholders
Page 15 of 23
REPORT N. ERA-REP-100
 Feedback from interviews in subsequent ERATV Working Party meetings.
The interviews were based on a “questionnaire” used as guideline for focus and consistency of
interviews.
6.3.
Key Findings
By opening the usage of ERATV to the registration of existing vehicles types, the ERATV
Specification in force would not significantly be affected, but database operations and
consultation will ramp up more quickly. There is therefore an initial added cost, borne essentially
by NSAs who carry out the type registration.
Benefits of voluntary registration would consist in easier strategic planning but would materialize
under certain conditions: the most important one could be the parallel feeding of the registers of
infrastructure (RINF) with data.
6.4.
Conclusions of the impact assessment
Overall, the impact assessment indicates limited costs associated with the extension of ERATV to
existing vehicles types. However, no clear and quantifiable benefits have been detected either.
Furthermore, voluntary extension of ERATV does not appear urgent given the remote (2018) date
of availability of RINF and the incomplete status of ECVVR. Pending, fundamental questions are
data quality, role of NSAs, and link with other registers. Indeed, the inclusion of existing vehicles
types in ERATV should be considered within the wider framework of the rationalisation of the
system of vehicle related registers that will commence in September 2013.
7. Relationship with Study on Registers
As follow-up to the Study on Coherence and Consistency of Registers [III] the Agency will establish
a Working Party on the Rationalisation of the Vehicle Related Registers (ERATV, ECVVR, VKMR,
register of certified ECMs) that will commence its works in September 2013.
The Working Party will take this Report and the Study on Coherence and Consistency of Registers
[III] as input.
In particular, the Working Party will answer the fundamental question identified by the Study as
starting point of any further evaluation of the benefits of voluntary usage of ERATV: is ERATV and in general the registers kept by Institutions- intended to be used in operation or, on the
contrary, is meant to be purely an administrative database?
8. Conclusions
No decisive elements have been found that recommend the immediate amendment of ERATV
Specification for the inclusion of existing vehicles types.
Page 16 of 23
REPORT N. ERA-REP-100
The benefits of voluntary registration of existing vehicles types in ERATV are not evident or cannot
be exactly quantified independently from the rationalisation of vehicle related registers.
The inclusion of existing vehicles types in ERATV will be reconsidered within the framework of the
Working Party on the Rationalisation of the Vehicle Related Registers (ERATV, ECVVR, VKMR,
register of certified ECMs) that will commence its works in September 2013.
The main findings of this Report will be used as input for the Working Party.
Page 17 of 23
REPORT N. ERA-REP-100
Annex 1: Definitions and abbreviations
Definitions
Table 1: Table of definitions
Definition
Description
Vehicle
Railway vehicle as defined in Article 2(c) of Directive
2008/57/EC (section 6 of Annex I of the ERATV Decision).
Type
Vehicle type as defined in Article 2(w) of Directive
2008/57/EC. Type must reflect the unit that has been subject
of the conformity assessment and authorisation. This unit may
be a single vehicle, a rake of vehicles or a trainset (section 6 of
Annex I of the ERATV Decision).
Manufacturer
Any natural or legal person who manufacturers a vehicle or
has a vehicle designed or manufactured, and markets that
vehicle under his name or trademark. The indication of
manufacturer in ERATV is for reference only; it is without
prejudice to the intellectual property rights, contractual
responsibilities or civil liability (section 6 of Annex I of the
ERATV Decision).
Authorisation holder
Entity that applied for and received the authorisation of type
of vehicle (section 6 of Annex I of the ERATV Decision).
Entity in charge
maintenance
Registration Holder
of
“An entity in charge of maintenance of a vehicle, and
registered as such in the national vehicle register” (Article 2(z)
of the Interoperability Directive and Article 3(t) of the Safety
Directive). The responsibilities of an entity in charge of
maintenance are defined in Article 14a of the Safety Directive
Entity responsible for immediately declaring any modification
to the data entered in the National Vehicle Register, the
destruction of a vehicle or its decision to no longer register a
vehicle, to the authority [Registration Entity] of any Member
State where the vehicle has been authorised as set out in
Article 33(3) of Directive 2008/57/EC.
Page 18 of 23
REPORT N. ERA-REP-100
Abbreviations
Table 2: Table of abbreviations
Abbreviation
CER
ECM
ECVVR
EPTTOLA
ERA
ERATV
IM
MS
NSA
NVR
PRM
RE
RH
RINF
RU
TSI
UIP
Definition
Community of European Railways and Infrastructure Managers
Entity in Charge of Maintenance
European Centralized Virtual Vehicle Register
European Passenger Train and Traction Operating Lessors'
Association
European Railway Agency
European Register of Authorised Types of Vehicle
Infrastructure Manager
EU and EEA Member State
National Safety Authority
National Vehicle Register
Persons with Reduced Mobility
Registration Entity
Registration Holder
Register of Infrastructure
Railway Undertaking
Technical Specification for Interoperability
International Union of Private Wagons Owners (Union
Internationale d’associations de Propriétaires de wagons de
particuliers)
UITP
International Association of Public
Internationale des Transports Publics)
UNIFE
Union of the European Railway Industries (Union des Industries
Ferroviaires Européennes)
VKMR
WP
Vehicle Keeper Marking Register
Working party
Page 19 of 23
Transport
(Union
REPORT N. ERA-REP-100
Annex 2: Reference documents
Table 3: Table of reference documents.
Ref. N°
Title
Reference
Version
I.
IU-ERATVAccompanying Report to the Agency
Recommendation on the specification of the European 20101213register of authorised types of vehicles
FinalReport
13/12/2010
II.
Recommendation on the specification of the European ERA/REC/07register of authorised types of vehicles
2010/INT
ERA/REP/15Study on Coherence and Consistency of Registers
2012
ERA/REP/01Report on authorisation of types of vehicles
2012/INT
20/12/2010
III.
IV.
Page 20 of 23
1/02/2013
30/04/2013
REPORT N. ERA-REP-100
Annex 3: Reference legislation
Table 4: Table of reference legislation
Ref. N°
Title
Reference
1. Regulation
2
(EC) No 881/2004 of the European Parliament OJ L 220,
and of the Council of 29 April 2004 establishing a 21.6.2004
European Railway Agency (Agency Regulation)
Version
As last amended
by Regulation (EC)
No 1335/2008 of
the European
Parliament and of
the Council
(OJ L 354,
31.12.2008)
2. Directive
3
2004/49/EC on safety on the Community's OJ L 164,
railways and amending Council Directive 95/18/EC on the 30.4.2004,
licensing of railway undertakings and Directive 2001/14/EC
on the allocation of railway infrastructure capacity and the
levying of charges for the use of railway infrastructure and
safety certification (Railway Safety Directive)
3. Directive
4
2008/57/EC of the European Parliament and of OJ L 191,
the Council of 17 June 2008 on the interoperability of the 18.7.2008
rail system within the Community (Interoperability
Directive)
As last amended
by Directive
2009/149/EC
(OJ L 313,
28.11.2009)
As last amended
by Directive
2009/131/EC
(OJ L 273,
17.10.2009)
Directive
2011/18/EU
(OJ L 57, 2.3.2011)
Directive
2013/9/EU
(OJ L 68,
12.3.2013)
4. Commission Decision 2011/665/EU of 4 October 2011 on
the European register of authorised types of railway
vehicles (the ERATV Decision)
5. Decision 768/2008/EC of the European Parliament and of
the Council of 9 July 2008 on a common framework for the
marketing of products, and repealing Council Decision
93/465/EEC
6. Commission Decision 2009/965/EC on the reference
document referred to in Article 27(4) of Directive
2008/57/EC of the European Parliament and of the Council
on the interoperability of the rail system within the
Community
Page 21 of 23
OJ L 263,
8.10.2011
OJ L 218,
13.8.2008
OJ L 57,
03.03.2011
REPORT N. ERA-REP-100
Table 4: Table of reference legislation
Ref. N°
Title
Reference
7. Commission Decision 2010/713/EU concerning the
modules for procedures for assessment of conformity,
suitability for use and EC verification to be used in the
Technical Specification for Interoperability
8. Commission Regulation (EU) No 201/2011 on the model of
declaration of conformity to an authorised type of railway
vehicle
9. Regulation (EU) No 445/2011 on Certification of ECMs
OJ L 319,
04.12.2010
10. Commission Recommendation 2011/217/EU on the
authorisation for the placing in service of structural
subsystems and vehicles under Directive 2008/57/EC of
the European Parliament and of the Council
11. Commission Decision 2007/756/EC of 09 November 2007
adopting a common specification of the national vehicle
register provided for under Article 14(4) and (5) of
directives 96/48/EC and 2001/16/EC (NVR Decision)
OJ L 95,
08.04.2011
Version
OJ L 341,
22.12.2011
OJ L 122,
11.05.2011
OJ L 305,
As last amended
23.11.2007 by Commission
Decision
2011/107/EU of 10
February 2011
(OJ L 43,
17.2.2011)
Decision
2012/757/EU of 14
November 2012
(OJ L 345,
15.12.2012) (This
amendment shall
apply from 1
January 2014)
Page 22 of 23
REPORT N. ERA-REP-100
Annex 4: Impact Assessment Report
IMPACT ASSESSMENT REPORT N. ERA-REP-100-EEV
ON
Extension of the ERATV to existing vehicle types
European Railway Agency – 120 rue Marc Lefrancq – BP 20392 - 59307 Valenciennes Cedex, France
Tél : +33 (3) 27 09 65 00 – Fax : +33 (3) 27 33 40 65
www.era.europa.eu
Page 23 of 23
REPORT N. ERA-REP-100-EEV
Table of Contents
1 SUMMARY ........................................................................................................................................................ 3
2 BIBLIOGRAPHY................................................................................................................................................... 6
3 TERMS AND ABBREVIATIONS ................................................................................................................................ 6
4 PROBLEM DESCRIPTION ....................................................................................................................................... 7
4.1
History ................................................................................................................................................ 7
4.2
Reason for impact assessment ........................................................................................................... 7
5 IMPACT ASSESSMENT METHODOLOGY.................................................................................................................... 7
6 SCENARIOS ....................................................................................................................................................... 9
6.1
Reference scenario ............................................................................................................................. 9
6.2
Project scenario .................................................................................................................................. 9
7 STAKEHOLDERS .................................................................................................................................................. 9
8 IMPACTS........................................................................................................................................................... 9
8.1
Cost impact, general ........................................................................................................................... 9
8.2
Database structure ............................................................................................................................. 9
8.3
Database capacity............................................................................................................................... 9
8.4
Database feeding .............................................................................................................................. 10
8.4.1
Data provision...........................................................................................................................10
8.4.2
Data input and verification .......................................................................................................10
8.4.3
Bottlenecks ...............................................................................................................................11
8.5
Database consultation ...................................................................................................................... 11
8.6
Link with other databases ................................................................................................................ 11
8.7
Administrative burden...................................................................................................................... 12
9 BENEFITS ........................................................................................................................................................ 12
9.1
Identification of benefits .................................................................................................................. 12
9.2
Quantification of benefits ................................................................................................................ 13
9.2.1
Route compatibility checks ......................................................................................................13
9.2.2
Commercial characteristics ......................................................................................................13
9.3
Is ERATV specification in line with the expected benefits? .............................................................. 14
10 OVERALL PERSPECTIVES ON IMPACTS ................................................................................................................... 14
10.1
Reflections on the project scenario .............................................................................................. 14
10.2
Questionnaire findings on usefulness of ERATV extension .......................................................... 15
10.3
Conclusions ................................................................................................................................... 15
11 EX POST ASSESSMENT ....................................................................................................................................... 15
Page 2 of 15
REPORT N. ERA-REP-100-EEV
1
Summary
The present report contains the outcome of the impact assessment with respect to the extended usage of
ERATV (European Register of Authorised Types of Vehicles). By opening the usage of ERATV to the
registration of types of vehicles placed into service before a recent date (namely 19 July 2010), the already
approved ERATV specification would not significantly be affected, but database operations and
consultation will ramp up more quickly. There is therefore an initial added cost, borne essentially by NSAs:
since such extended usage would be voluntary, requesting entities would initiate the type registration
process if they have a good (business) reason to do so. However NSAs would have to process the data in
two steps: type registration in ERATV, then assignment of vehicles previously recorded in NVRs to
registered types (update of NVR records).
Benefits of voluntary registration would consist in easier strategic planning: which existing vehicle types are
available, that would fit a given commercial purpose and be able to run on certain lines. Better “visibility”
of vehicle characteristics (when vehicles are assigned to a registered type) could also benefit keepers and
lessors.
Benefits would materialize under certain conditions; the most important one could be the parallel feeding
of the registers of infrastructure with data. ERATV and RINF specifications already ensures that the
infrastructure and vehicle data regarding technical compatibility would match.
Further understanding of the possible benefits and costs associated with the extension of ERATV to existing
vehicles has been developed through a series of questionnaires and interviews with relevant stakeholders
(NSAs, RUs, keepers, manufacturers and EPPTOLA).
This information collection and additional analysis by the Agency indicates that there is a wide variety of
views, and no party could formulate and substantiate quantifiable benefits (even when ERATV voluntary
registration was mentioned “highly desirable”). The mentioned benefits were:
•
Preliminary compatibility checks of vehicle types with network, pre-requisites being
•
ECVVR completed (was expected for 2011, but the NVR of several Member States are not
yet connected to VVR)
•
RINF availability, including existing infrastructure (expected by 2018), although the
implementation may be more challenging in some countries
•
Contribution to Cross acceptance
•
Fleet statistics, prospective rolling stock market information (one supplier)
•
None [UIP], or (locally) low
Page 3 of 15
REPORT N. ERA-REP-100-EEV
Furthermore, although the extension of an existing register (ERATV) to voluntary usage seems « harmless »,
creating a right for one party (the data holder) also induces obligations on other parties (NSAs, Agency), and
one has to make sure that the latter will be able to fulfil their obligations, as small as they may appear.
Indeed, both NSAs and Agency have to deal with budgetary limits.
Other findings from the ERATV questionnaires and follow-up discussions include the following:
Data quality
NSAs would not accept liabilities in relation with the correctness of data, but even with this legal precaution
will not solve a more fundamental problem, which is data quality and usefulness. A data validation process
(content, not just format) should be defined and agreed. An active role in the understanding of types and
some coordination between NSAs seem required.
Data coverage
Voluntary registration does not imply that all existing types would become available, even after a transition
period. Only one NSA considered partial coverage to be a potential problem, and would encourage a
systematic link between ERATV and NVR.
Database coordination
RSRD² database, fulfilling the requirements of the TAF TSI, is deemed fully suitable for wagons. It was
suggested to have a master/slave relationship between ERATV and RSRD², at least, rather than duplicate
databases. This would require further investigations.
Role of NSAs
The analysis of questionnaire results was followed by two roundtable discussions, about role of NSAs and
direct data input (by the data owner). It appears there is no agreement on the role of NSAs (not involved /
NSA oversight with veto possibility / active NSA role).
As a conclusion, voluntary extension of ERATV does not appear urgent (given the remote date of availability
of RINF). Pending, fundamental questions are data quality, role of NSAs, and link with RSRD² in the case of
wagons. Indeed, the inclusion of existing vehicle types in ERATV should be considered within the wider
framework of the rationalisation of the system of vehicle related registers that will commence in
September 2013.
However, one potential role of ERATV voluntary registration has not yet been examined, but is expected to
be examined further by the Agency in the second half of 2013: the potential role of ERATV in the “Inventory
of Assets” foreseen by the draft revised PRM TSI (ERA/CON/2012-07/INT). The inventory of assets might
Page 4 of 15
REPORT N. ERA-REP-100-EEV
induce an obligation (applying to a subset of the data) where we only consider, for the time being,
voluntary registration.
Page 5 of 15
REPORT N. ERA-REP-100-EEV
2
Bibliography
1. ERA. European Register of Authorised Types of Vehicles (ERATV). 2010. IU-ERATV-20101213-Final Report.
2. European Commission. Interoperability directive (recast). 2008/57.
3. European Commission. Impact Assessment Guidelines. 2009. SEC(2009)92.
4. ERA. Application Guide for the European Register of Authorised Types of Railway Vehicles (ERATV). 2012.
ERA/GUI/01-2012/INT
5. ERA. Economic Evaluation: Methodology Guidelines. 2007
3
Terms and Abbreviations
Table 1 : Terms
Term
Definition
Agency
The European Railway Agency (ERA)
ECVVR
European Centralised Virtual Vehicle Register
ERATV
European Register of Authorised Types of Vehicles
FTE
Full Time Equivalent; a measure for workload of staff. Should include
supplemental work hours and deduct sick leaves etc.
IA
Impact Assessment
NVR
National Vehicle Register
RINF
Register of Infrastructure
RISC
Railway Interoperability and Safety Committee
RSRD²
Rolling Stock Reference Database
TSI
Technical Specification for Interoperability
WP
Working Party
Page 6 of 15
REPORT N. ERA-REP-100-EEV
4
Problem description
4.1
History
4.1.1.1
The European Railway Agency has prepared a specification for the European Register for
Authorised Types of Vehicles (“ERATV”) in 2009 and 2010. This specification has been prepared
on the basis of the legal prescriptions in Article 34 of the Interoperability Directive 2008/57.
4.1.1.2
This specification was submitted to the opinion of the RISC Committee in June 2011. It did not
undergo any impact assessment, as it resulted directly from an existing legal constraint. Also,
since ERATV is supposed to be hosted by the Agency (as opposed to the registers of
infrastructure), there were lesser concerns. Following its acceptance by the RISC Committee the
ERATV Commission Decision was published in October 2011 as Decision No. 2011/665/EU on
the European register of authorised types of railway vehicles. ERATV has been in operation since
January 2013
4.1.1.3
The purpose and scope of the ERATV are detailed in the final report (1) issued by the Agency. In
particular, the voluntary use of ERATV for existing vehicles, the type of which is not authorised
in the sense of the Interoperability Directive (2), Art. 26, was left for further analysis.
4.2
Reason for impact assessment
4.2.1.1
5
Since this extension of use of ERATV is not already mandated by the Directive, an impact
assessment should logically be conducted. In this context it should be noted that an analysis of
voluntary registration has been undertaken. Furthermore, the amended ERATV specification has
been defined with minor changes (e.g. definitions, and the fact that not all parameters
describing the types of existing vehicles would need to be registered).
Impact assessment methodology
5.1.1.1
Overall, the general framework for the impact assessment regarding extension of ERATV to
existing vehicle types is derived from the Agency’s Economic Evaluation Guidelines [5].
Furthermore, the structure of the proposed assessment also follows closely the
recommendations included in the European Commission’s Impact Assessment Guidelines [3].
5.1.1.2
The key principle of the impact assessment is the comparison of the reference scenario (Donothing or Do-minimum) with one or several project scenarios (as outlined in Section 5). This
will allow identification of effects on key aspects that could be caused by change regarding the
ERATV.
5.1.1.3
The core part of the impact assessment is based on a cost-benefit analysis (CBA) perspective
involving a consideration to the costs and benefits generated relative to the reference scenario.
This impact assessment utilises quantitative and qualitative analyses as available.
5.1.1.4
In accordance with the Agency’s Economic Evaluation Guidelines [5], the impact assessment
should examine main benefits and costs for different categories of stakeholders (e.g. railway
Page 7 of 15
REPORT N. ERA-REP-100-EEV
undertakings, keepers, infrastructure managers, rail manufacturers, NOBOs, Government, etc.)
due to the proposed changes of ERATV.
5.1.1.5
An important aspect in the impact assessment is to ensure that all significant assumptions used
are thoroughly validated such that the conclusions drawn are robust.
5.1.1.6
For this impact assessment the following data collection methods have been used in order to
provide the required information to examine the expected consequences:
5.1.1.7

Interviews (telephonic, or visits) with selected stakeholders

Feedback from interviews in subsequent ERATV Working Party meetings.
The interviews were based on a “questionnaire” used as guideline for focus and consistency of
interviews. In particular, the following items were included in the questionnaire:
•
Cover
o
•
•
•
•
•
Data traceability and data protection are ensured as with ‘classical’ questionnaire
Scope
o
Likelihood of voluntary registration
o
Obstacles to voluntary registration
Data
o
Subset of fields (Yes/Opt./No)
o
Data verification
Process
o
Timeframe for handling one request
o
Timeframe for handling ‘most’ requests
Costs
o
Unit costs (per voluntary registration)
o
Frequency
o
Charging scheme
Benefits
Page 8 of 15
REPORT N. ERA-REP-100-EEV
6
Scenarios
6.1
Reference scenario
6.1.1.1
6.2
Project scenario
6.2.1.1
7
The ERATV specification is initially adopted as above in the reference scenario. Then the
proposed and amended specification (with inclusion of existing vehicle types) is the project
scenario with the changes introduced by 2013.
Stakeholders
7.1.1.1
8
The reference scenario consists of the ERATV specification without amendments as set out in
Commission Implementing Decision No. 2011/665/EU. The ERATV server is implemented by the
Agency on that basis.
The impacted stakeholders are: vehicle owners, vehicle keepers, RUs, type authorisation holders
(usually owners or manufacturers), NSAs, ERA, the general public (since ERATV is a publicly
accessible database). Each of these stakeholders is expected to be influenced by the extension
of scope of ERATV.
Impacts
8.1
8.1.1.1
8.2
8.2.1.1
8.3
8.3.1.1
Cost impact, general
Expected impact of the changed specification and use of ERATV is deemed, a priory, to impact
the following:

Database structure

Database capacity (server storage capacity)

Database feeding

Database consultation (server processing capacity, quality of service)
Database structure
The amended specification introduces no significant change in the structure of the database
(addition of a few fields). There would be no significant impact on the server side. Anyway there
would be no impact on client side, since ERATV consultation rests on a web-based application.
Database capacity
The capacity of the database has previously been set at 35 000 types (at most). This figure is
certainly a ceiling, resulting from the consideration of a very fragmented fleet (as currently
observed) and a 70-years “lifetime” of vehicle types (production span for a given type + lifetime
of delivered vehicles)
Page 9 of 15
REPORT N. ERA-REP-100-EEV
8.3.1.2
This figure is rather low by today’s IT standards, and revising it to a lower value would not
reduce project costs. Each recorded vehicle type consists in text data only (no pictures, etc.),
resulting in a reasonable maximum storage figure.
8.3.1.3
The estimate bears no relationship with the registration of types of existing vehicles, as it
reflects the future diversity of types of the whole vehicle fleet, on a “business as usual” basis.
There is a risk that due to the possible difficulty in identifying existing vehicles types (no type
examination certificate; vehicles of that type have each undergone an individual history of
upgrades/renewals) the registration holder will tend to declare more distinct types than
necessary. However, taking into account the limited set of mandatory fields required for existing
vehicle types (see para. 8.4.1.1) the impact on database capacity should be low.
8.4
8.4.1
Database feeding
Data provision
8.4.1.1
Data provider (e.g. the registration holder): collecting the necessary data describing the type
may be a significant amount of work, especially if the type is “old”, or has undergone
modifications (adaptation to commercial needs, or changes due to maintenance). On the other
hand, not all data are required in the case of voluntary registration of types of existing vehicles.
The “minimum” amount may represent about ¼ of all ERATV data record entries.
8.4.1.2
We assume that the data provider will undertake the voluntary data collection to submit the
type for registration only if there is a deemed benefit (for him) exceeding the cost.
8.4.1.3
In a few cases, stakeholders hold already similar data in a database that includes all types, which
should simplify or reduce the data input workload.
8.4.1.4
This effort is however difficult to estimate: the list of minimum data is included in the amended
ERATV specification, but NSAs might place more or less emphasis on evidence to be provided, to
ascertain the data in absence of third party verification. See also next section.
8.4.1.5
It should be noted that if tools for the bulk input of data into ERATV from existing databases
were available the data input would be indeed be simplified. Such tools for bulk import of data
are though not available in the current ERATV release and are not mentioned in the amended
specification.
8.4.2
Data input and verification
8.4.2.1
The NSAs will examine the submitted type information, input the data, and possibly verify the
input (depending on the quality target). The corresponding effort may be estimated at 2h to half
a day (input only) per added type.
8.4.2.2
As per current ERATV specification, the search for duplicates should then be carried out by the
Agency, using information found in ERATV. This would imply the search, in ERATV, for types with
similar characteristics and, in case of coincidence, contact with the NSA. The NSA, in turn, may
have to liaise with the registration holder to clarify the matter.
Page 10 of 15
REPORT N. ERA-REP-100-EEV
8.4.2.3
Verification on Agency side will be essentially formal, and mostly automatic by means of the
web interface design: utilisation of Edit boxes with filters, dropdown lists, etc. The expected
impact on the Agency staff is estimated at 1 FTE, no matter if the ERATV specification is
amended or not (no significant impact).
8.4.2.4
The ERATV does not specify evidence to support data. As a matter of fact, checks against ERATV
do not replace checks according to OPE TSI (see ERATV report).
8.4.3
Bottlenecks
8.4.3.1
Even if the data input effort seems low, beware of bottleneck effects. The ERATV specification
(original or amended) set the obligation for NSA and the Agency to process data related to
voluntary registration, even though no time constraints are defined like in the case of
mandatory registration.
8.4.3.2
This requirement may be difficult to comply with, even with increased, temporary means, if
complete type databases are submitted for input into ERATV.
8.4.3.3
The lack of time constraints for the registration of existing types of vehicles already placed in
service seems reasonable, given the actual needs (see benefits part below).
8.5
Database consultation
8.5.1.1
Database consultation will consist in two steps: type search, then display of search results (with
possible data download in pdf format, or similar).
8.5.1.2
In the beginning, negative searches will probably be the most frequent event. Impact of
negative searches on the server is, roughly said, proportional to the size of the database.
Registering existing types will increase the database size (in the beginning, not overall) and slow
down the search process.
8.5.1.3
In addition, having existing types recorded early in ERATV will increase the number of positive
searches, resulting into more data transfers. Positive searches will (probably) stimulate more
searches.
8.5.1.4
Since most users are “public” (as opposed to especially identified users in NSAs and ERA), there
is no easy distinction between business users (RUs, IMs…) and other users.
8.5.1.5
Registering existing types will therefore, probably, affect the overall quality of service in the
initial phase. Server reaction times are however not part of the ERATV specification.
8.5.1.6
Information about server traffic could be drawn from existing public databases hosted by the
Agency. It may well be that the minimum standard investment here would be amply sufficient
to cope with the traffic in both scenarios.
8.6
8.6.1.1
Link with other databases
NVR records will hold a reference to types defined in ERATV through a 10-digit key to be used in
field 5 of NVRs. This does not imply an IT link, which is not currently foreseen.
Page 11 of 15
REPORT N. ERA-REP-100-EEV
8.6.1.2
NVRs are not tailored for massive consultation (limitative access rights: keeper / RU / …). NVRs
are not public. Some information may be sensitive (e.g. manufacturing year?).
8.6.1.3
For the purpose of impact assessment, we take NVR specifications as they are today, and ERATV
as currently specified, except minor elements (IT link with NVRs is considered a major change).
We do not assess “IT-based link between NVRs and ERATV” as an option here.
8.7
Administrative burden
8.7.1.1
As per impact assessment guidelines (3), section 8.4 “Assessing administrative burdens”:
For all policy options, the IA should provide details of the information obligations for
businesses, for citizens and national/regional/local administrations that are likely to be
added or eliminated if the option were implemented.
8.7.1.2
In the present context, the “policy option” is illustrated by the project scenario (section 10). The
possible administrative burden corresponds to the (differential) workload imposed on NSAs and
the Agency, if the usage of ERATV were extended to existing types, and if this possibility were
actually used. There is no (differential) burden on entities registering the existing types, since
the possibility of registering existing types is no legal obligation (it is a right), nor is it a de facto
obligation1.
8.7.1.3
A very preliminary estimate of cost impact would be an additional 0.5 FTE (staff full time
equivalent) for NSAs if voluntary type registration is accepted 2. The figure may rise to 3-4 FTE in
the case of “bigger” NSAs. With time, the registration of new types will become the main
activity, and registration of existing types will recede (over one decade, maybe), not because all
types would have been registered, but because of lack of interest in registering the remaining
ones. In addition, there would also be a cost impact incurred by the Agency in terms of
additional resources required although likely to be of relative limited importance.
9
Benefits
9.1
9.1.1.1
Identification of benefits
The main benefit identified by the Working Party that is specific to the amended specification is
“strategic planning”, i.e. the ability to identify vehicle types with adequate characteristics for a
given traffic (route compatibility, type of loads…). RUs do not need ERATV to inspect the
characteristics of the vehicles they own. Most wagons keepers are not RUs however, and
locomotive leasing or rental is a growing trend.
1
To be confirmed. With respect to administrative burdens, the Commission Guidelines do not seem to consider de
facto obligations, but only legal ones. The Agency considers that in the very complex area of railway regulation, de
facto obligations are more likely to appear than in the general case, hence the cautious wording.
2
Under the condition that registration time constraints are “relaxed” for existing types
Page 12 of 15
REPORT N. ERA-REP-100-EEV
9.1.1.2
Reciprocally, keepers and lessors would see an interest in recording their vehicle types in
ERATV, in order to make apparent the usability of their fleets, and in order to avoid responding
to individual queries.
9.1.1.3
Whether RUs would volunteer to publish the characteristics of the fleet they own and operate
themselves is less clear.
9.1.1.4
Of course “strategic planning” already takes place, but it would be facilitated by the availability
of vehicle type data in ERATV.
9.1.1.5
The ERATV database is accessible to the public for free. The corresponding impact needs to be
evoked. ERATV does not contain photos, drawings, historic backgrounds or service records, so
railway publishers are certainly not threatened. Academic researchers (transport economics,
etc.) could be highly interested, although ERATV does not provide indications concerning fleets
– access to the ECVVR would be necessary here (but ECVVR is not publicly accessible). Here
again, some national vehicle registers may be accessible in accordance with the possibility
provided in the NVR Decision 2007/56/EC to grant access to NVR to ‘other legitimate users’.
9.1.1.6
However, ERATV does not provide any link to the vehicle registers; the link is in the opposite
direction. Strategic planning cannot take place if identification of the actual fleets corresponding
to a registered type is not possible. Voluntary registration of types would not be very useful if
NVRs would not contain references to registered types. Initially (2013), we reckon that ECVVR
will be fairly complete (i.e. existing fleets will be registered in the NVRs), but as long as the
corresponding types are not registered in ERATV, the link between NVRs and ERATV cannot be
established: the records in the NVR are expected to hold a reference to the unique identifier of
a type in ERATV.
9.1.1.7
Following the voluntary registration of a type, the NVR records for vehicles corresponding to the
type should be updated..
9.2
9.2.1
Quantification of benefits
Route compatibility checks
9.2.1.1
Vehicle characteristics related to route compatibility are only useful if route characteristics are
known with a matching degree of detail. The register of infrastructure (RINF) has been designed,
and the ERATV specification was developed to be technically consistent with RINF.
9.2.1.2
The full availability of data in RINF (including data for lines already placed in service) is expected
by 2018.
9.2.1.3
This suggests that populating ERATV with (useful) existing types should also be concluded until
2018.
9.2.2
9.2.2.1
Commercial characteristics
Current ERATV specification allows to record some limited commercial or performance data, for
instance:
Page 13 of 15
REPORT N. ERA-REP-100-EEV
9.2.2.2
9.3

Letter marking of wagons (e.g. meaning “a tank”, but not what kind of fluid)

A few performance indicators (power, but not tractive effort vs. speed)
As agreed by the Workgroup (31/5/2011), the impact assessment has not assumed any record
field that is not included in the current specification.
Is ERATV specification in line with the expected benefits?
9.3.1.1
Discussions within the Working Party took place as to whether ERATV should be an “operational
register”, or a “statistical” one. It should be mentioned that this issue was also considered as
part of the Study on Coherence and Consistency of Registers and related workshops. The
question relates to the recording of new types, or updating a type already registered.
9.3.1.2
The currently specified time frame for submitting a new type authorisation is 20 working days
(10 working days to validate a modification of a type authorisation) while 5 working days is
provided for in case of suspension/withdrawal. This would result in a delay between, for
instance, the changes in usage restriction of a given type and the update of this restriction in
ERATV. Since however the corresponding fleet will be introduced gradually (with vehicles
conforming the new type being gradually introduced into NVRs), this delay may not be relevant
to the “strategic planning” benefit.
9.3.1.3
Quality of service is not fully defined in the ERATV specification. In both the original and the
amended one, the specified availability is 98%. This is deemed adequate for reaping the
mentioned benefits.
10 Overall perspectives on impacts
10.1
Reflections on the project scenario
10.1.1.1
The most likely project scenario would be the full introduction of “useful” existing types into
ERATV in the time period 2013-2018.
10.1.1.2
Voluntary data input by RUs, keepers, lessors, etc. is supposed to be more than compensated by
their expected savings (querying of one central database instead of multiple sources), improved
overall data availability and easier strategic planning.
10.1.1.3
The only noteworthy cost impact would be the workload of NSAs to actually record the data,
and of the Agency to check for duplication as well as to check compliancy with the specification
(see above 8.4.2). NSAs and the Agency have though no direct benefit (main expected benefits
are for RUs, keepers, lessors in terms of their strategic planning and data availability).
10.1.1.4
Assuming that processing time constraints would be relaxed for existing types, the significance
of this impact was estimated on the basis of average figures with respect to NSAs, see section
8.7 on administrative burdens. This indicated a relative low impact on NSA resource
requirements (around 0,5 FTE for most NSAs, although NSAs in the biggest EU countries may
require somewhat additional resources). The key question then is the perceived benefits and
Page 14 of 15
REPORT N. ERA-REP-100-EEV
how these compared to the likely costs. This is addressed in the following section drawing on
the information from the telephone interviews.
10.2
10.2.1.1
Questionnaire findings on usefulness of ERATV extension
The following is a synthesis based on interview responses and feedback from selected NSAs (DE,
FI, FR and IT), sector organisations (EPPTOLA and UIP) and companies (Siemens, SNCF). In
particular, these interviews showed that there is a variety of views on the usefulness of the
extension of the ERATV to existing vehicles based on voluntary registration. Indeed, no
stakeholder expressed any clear, quantifiable benefits that could outweigh the increase in
administrative burden on NSAs (and the Agency). The main reported benefits concerned the
following:

Simplification of preliminary compatibility checks

Facilitation of cross-acceptance (granting of additional authorisations) of vehicles

Fleet statistics
10.2.1.2
It is noted that these possible benefits depend on the clarification of the purpose of the system
of vehicle registers and the different interfaces. This clarification will be developed by a
dedicated Agency Working Party which will commence in September 2013 with expected
intermediate results in 2014.
10.2.1.3
Other respondents did not see any benefits linked to the extension. Further doubt on the
benefits is also introduced from Working Party discussions indicating limited willingness by NSAs
to validate the provided registration data.
10.3
10.3.1.1
Conclusions
Overall, the impact assessment indicates limited costs associated with the extension of ERATV
to existing vehicles. However, no clear and quantifiable benefits have been detected either.
Furthermore, it is likely that there is no urgent need given the remote date of availability of RINF
and the incomplete status of NVRs. As such the possible extension of ERATV to existing vehicles
could be revisited following the conclusion of the Agency work on rationalisation of vehicle
registers.
11 Ex post assessment
11.1.1.1
As the Agency has implemented ERATV, there is no need to define in detail, at the present
stage, data requirements in view of ex post assessment. Project costs will be available, and
utilisation of statistics will be defined in due time.
Page 15 of 15