Proposal for a Regulation concerning type-approval requirements for the
deployment of the eCall in vehicle system and amending Directive
Date of application (Recital 16, Articles 7 and 12)
The industry will need sufficient lead-time once the delegated acts (and/or implementing acts) specifying the technical requirements and precise test procedures are published. 36 months is the standard leadtime requested by the industry to develop and test safety systems. Moreover, for eCall to function, the infrastructure to receive and handle the calls must be in place. ACEA, therefore, welcomes the agreement found between the Member States, the European Parliament and the Commission, whereby “Member States shall deploy at least 6 months before the date of application of the Regulation concerning the type-approval requirements for the deployment of the eCall in-vehicle system and amending Directive 2007/46/EC, and in any case no later than 1 October 2017, the necessary eCall PSAP infrastructure required for the proper receipt and handling of all eCalls”. A staggered approach with infrastructure being updated at different dates in Member States is not a feasible scenario for the auto industry: 112-based eCall in-vehicle systems should become mandatory to type-approve new types of vehicles after all EU Member States have the necessary PSAP infrastructure operational. Moreover in order to guaranty the functionality over the lifetime of the vehicles in the field, the infrastructure, including mobile networks, PSAPs, and GNSS systems, must be available for at least this period of time.
Open platform (Recital 9, Article 10a(3))
Our industry cannot accept that the 112-based eCall in-vehicle system should be based on an open platform, a concept for which there is currently no definition. eCall is a safety system, which does not require an ‘open platform’ to function. The concept of open platform raises a number of issues (including among other safety, liability and data protection challenges) which need to be explored before it become the basis for vehicle systems. Moreover the standards and technical requirements of a possible future open-platform legislation would change the 112-based eCall system technically and could imply a complete revision of the eCall Regulation. 112-based eCall should remain focused on safety and separated from a possible future open telematic platform. In this respect ISO work on the Vehicle Station Gateway, where AFCAR participates, hould be taken into account, starting with the settled distinction between RMI over the air, remote driver behaviour services (e.g. insurance) and eCall. A possible open telematic platform should be discussed separately, as foreseen in the ITS Action Plan.
Repair and Maintenance Information – RMI (Recital 8, Article 5(6))
RMI should not be confused with the open platform. RMI is about the conditions and modalities under which repairers have access to the information necessary to carry out repair and maintenance tasks on a vehicle. These provisions are laid out in Regulation (EC) No 715/2007 of the European Parliament and of the Council of 20 June 2007 on type approval of motor vehicles with respect to emissions from light passenger and commercial vehicles (Euro 5 and Euro 6) and on access to vehicle repair and maintenance information. Should the legislators wish to modify the existing provisions, it should be done by amending Regulation 715/2007.
Galileo (Recital 6, Article 5, paragraph 3)
Any satellite constellation must be certified before it can be used for all terrestrial applications. It is a sine qua non condition. The certification of a constellation implies checking the diffusion of a valid signal (date validity and signal health status) as indicated in ‘European GNSS (Galileo) Open Service - Signal in Space Interface Control Document’ (p.53)1. If the constellation is not certified (it is not today) and therefore the validity of the signal is not verified, Galileo cannot be used to calculate the position of the vehicle sending an eCall as it could induce an erroneous positioning of the crashed vehicle! Demanding compatibility with the Galileo and EGNOS systems does not take into account the need to validate the behaviour of the system (including receivers) in all situations (requiring a complex validating plan in an industrial context). The fact that Galileo partly functions does not mean that it can be declared available and reliable for commercial applications, and the fact that specifications are available does not mean that the real system will behave as foreseen by the specification. Compatibility should only be required for operational and validated systems.
The principle of technology neutrality should be applied in this legislation enabling OEMs to innovate further and develop effective solutions. Actual systems do not preclude that other relevant innovative, cost efficient solutions may soon be available on the market. Therefore, a range of solutions should be recognised as valid provided they are compliant with minimum technical specifications. Favouring one olution (such as an embedded system) might distort competition by ruling out other viable solutions from the market. It will also limit innovation and lead to usage of outdated technologies. TPS A number of manufacturers have already invested considerable time and money into developing private eCall solutions should be allowed to offer such systems to their customers.
ACEA welcomes the fact that both the Parliament and Council accept the co-existence of the 112-based eCall and third party systems (‘private eCall’). It also supports the horizontal amendment proposed by the Parliament, which makes it clear that the proposed Regulation only apply to the public 112-based eCall.
Mobile-phone based solutions Mobile-phone based eCall systems already exist in Europe and 3rd countries and have proven to be reliable. In line with the principle of technological neutrality, ACEA calls on the legislators not to rule out uch systems and therefore supports the Council’s approach.