OBD provision and data access included in provisional Type-Approval legislation

Published:  04 January, 2018

The IAAF and FIGIEFA have welcomed news that crucial provisions on the OBD connector and access to RMI have been included in the proposed EU legislation on Vehicle Type-Approval regulation.

The EU Council's main preparatory body, COREPER, recognised the need for the aftermarket to maintain access to diagnostic and RMI-related data. It also clarified that access will be granted while the vehicle is in motion.

The new legislation intends to clarify that RMI and spare parts identification information shall also be provided in a machine readable and electronically processable structure. RMI information has often been made available to independent repairers in an unusable format.

FIGIEFA’s aim is that access to in-vehicle data remains possible, with the issue to be swiftly addressed in 2018 by the EU Council.

Hartmut Röhl, FIGIEFA president said: “The new vehicle type-approval and its RMI legislation, once approved, will represent a step forward and will have a positive impact for the entire automotive aftermarket and mobility services industries.

“However, the EU Commission must now find a solution on how to address the telematics access to the ‘connected car’, and we call upon it to start working in 2018 on the interoperable, standardised, secure and open-access platform.”

Significant step

Wendy Williamson, IAAF chief executive said: “This is fantastic news, and although not the end game it’s a significant step towards keeping the OBD port alive.”

While it has been clarified that the OBD port shall remain open when the vehicle is in motion, some vehicle manufacturers have introduced measures to prevent access to the OBD port.

Wendy continued: “The missing OBD connector would impact not just on garages but the entire spare parts supply chain including manufacturers, distributors, producers of diagnostic equipment and dedicated software for the OBD connector, as well as millions of consumers who would no longer have a competitive choice in vehicle servicing and repair. This positive step marks the next stage in our fight and we’ll keep lobbying until we successfully reach that end game.” 

The agreement will now need to be approved by the EP IMCO Committee before it is submitted for approval. If approved, the new regulation will come into play from 1 September 2020.

Related Articles

  • SO FAR... so good 

    You may have read about some of the challenges that the aftermarket has faced over the last year or two as part of the vehicle Type Approval revisions – with their inherent ‘rights of access to repair and maintenance information’ and the associated fight to maintain access to the vehicle data via the ever-so-not-so-humble 16 pin OBD connector.

    The draft vehicle Type Approval document has been agreed by the European Commission and the Council (Member States), but has now to be approved by the European Parliament before becoming the final version which in turn, will become new legislation. However, as many of the key aftermarket amendments were tabled by the Parliament, it seems unlikely that these will be changed, but there is always an uncertainty until the final plenary vote is done.
        
    So once agreed, that will be that, as they say. Unfortunately not, as the devil is in the detail.

    Legal reference
    Firstly, there is the additional problem of existing Block Exemption and Euro 5 Regulations which do not provide the critical legal reference to enable access to in-vehicle data beyond just emissions. The standardisation requirements are included, but not the data and information for the wider diagnostic, repair and maintenance data. This means that vehicle manufacturers can claim that access to the vehicle and the corresponding ‘wider data’ does not have to be provided. This is currently being challenged by the Aftermarket Associations in Brussels, but no solution has yet been agreed for those contentious claims and there will be many vehicles on the roads with restricted access before a workable solution can be agreed and implemented.

    As vehicle manufacturers are likely to be in contradiction with these existing Type Approval requirements, it is also likely that they will have to provide access, but this may well be through the use of electronic certificates. As each vehicle manufacturer has their own certificate strategy (process, access criteria, data available etc.), this is still a significant problem and in some cases could mean multiple certificates are needed to work on the different vehicle systems on specific models. It is also important that certificates can be used without the necessity of having to use the vehicle manufacturer’s dedicated diagnostic tool and an online connection to their server to generate the required certificate when using the 16 pin connector.

    However, the new vehicle Type Approval legislation should now provide the legal reference for the physical connector and critically, also contain a reference to the data needed for diagnostics, OBD, repair and maintenance, but beyond these important requirements there are still other elements which have yet to be discussed or agreed.

    Logical cascade     
    These other issues revolve around the secure access for independent operators, together with the exact data that will be made available once access has been granted. This may sound strange, but the 16 pin OBD port is increasingly seen as a high security risk access point into the in-vehicle networks. Consequently, some form of controlled access is highly likely to be implemented, even for such seemingly mundane tasks as checking safety system trouble codes when conducting an MOT test. This is also likely to be a ‘certificate based’ system and this introduces a whole range of new challenges!

    To understand these various issues more clearly, there is a logical cascade which starts with the legal requirement for a connector to be fitted to a vehicle. This is covered as part of vehicle Type Approval legislation, and this legislation also includes the need for the connector to be standardised from both the aspect of the physical shape and connector pin layout, but also what data or information is needed for emission systems, as well as the communication protocols that must be used. All these legislative elements have been in place for more than two decades, but the wider use of the 16 pin connector for diagnostic, repair and maintenance requirements had until the current revision of the vehicle Type Approval legislation, not been legally referenced. Now that this has (hopefully) been addressed, the next key discussions will be about who can access the vehicle via this connector, how this can be authenticated and once access is provided, what data, information and functions will be supported.

    As mentioned earlier, this is likely to require electronic certificates, but to avoid the ‘wild west’ of different processes, access conditions and data availability, a standardised process should be considered by the legislator which also uses a single and independent point of access for certificates from all vehicle manufacturers. It should also be possible to access in-vehicle data without a certificate when the vehicle is in the workshop, although software updates may require certificates. When the vehicle is being driven, ‘read-only’ data should still be available and a certificate should only be needed if some form of ‘functional’ testing is required, but this should be considered as the exception. As there is an increasing use of ‘plug-in’ devices being used to allow remote communication with the vehicle when it is being driven for services such as insurance, or remote monitoring for prognostics and predictive maintenance, arguably, the importance of the OBD connector is increasing for these telematics services – even if the data it can provide is restricted in relation to what is available via the vehicle manufacturers’ embedded
    telematics systems.

    Further requirements
    Once data is accessed, the new General Data Protection Regulation (GDPR), which comes into force in May this year, will impose further requirements for the use and handling of personal data.  A fundamental issue will be that much of the data contained in the vehicle can also be considered personal data and is subject to data protection legislation. Critically, the customer must give their consent to the use of this data by a positive action or statement – it cannot be assumed.    

    As you can see, it may be ‘so far, so good’, but the simple task of continuing to plug into the 16 pin connector and diagnosing or repairing the vehicle is going to be far from simple, with many hurdles and challenges yet to be addressed, but the aftermarket associations, both in the UK and with their pan-European partners, are continuing to fight for the ability to do so.


    xenconsultancy.com

  • Brexit and BER: IMPACT 

    What are the possible outcomes of Brexit for the UK aftermarket and should we be concerned?

  • ‘Grassroots insight’ plays influential role in crucial Type-Approval legislation vote 

    The European Parliament’s IMCO committee have approved several key amendments to Vehicle Type-Approval legislation proposals, which include the aftermarket maintaining in-vehicle data access via the OBD port.

  • Aftermarket scenario planning  

    Definition of uncertainty:
    a state of having limited knowledge where it is impossible to exactly describe the existing state, a future outcome, or more than one possible outcome.

  • Immobilisers and (in)security 

    We need to talk about security. Why? Because deliberately or not, its effects are mutating our opportunities within the automotive aftermarket. We need to understand more about it and, at some point, to try to anticipate the eventual set of circumstances to which it might lead. As they say, forewarned is forearmed.

    We’ll begin by looking at an example of a recent security system and checking out its inner workings. We’ll review its potential vulnerabilities and assess the need for, and impacts of, increased security. First though, we’ll cover some general concepts, to keep in our minds the bigger picture regarding possible motivations for increased security.


    Security
    Security is the protection of things having value, where they might be at risk from theft or attack; i.e. when they have, or are perceived to have a vulnerability. Security aims to prevent an agent of ill-intent (e.g. criminals, intruders, missiles, or computer-viruses etc.) from gaining access. The consequence of this is the introduction of barriers to those requiring legitimate access, such as owners, occupiers, citizens or data-holders. This dichotomy is at the heart of all security implementation issues. This always begs the question; what level of security balances an intended degree of protection from risk, with the subsequent barriers to legitimate access or freedoms?

    As the assessment of risk primarily determines the necessary level of security, it is not hard to imagine that superficially legitimate security concerns can be used to justify limiting access to a favoured group. It’s a simple trick, just inflate the perceived risks and exaggerate the vulnerabilities where necessary. A similar mechanism can be used in a health and safety environment, where legitimate but undesirable behaviours in the eyes of the decision makers can be quashed by deliberate overstatement of the perceived risks. When loaded with the weight of moral absolutes (“lives are at stake”), the arguments seem powerful but are they really intended to shut-down reasoned debate regarding the actual risks? Anyway, the point is, we cannot have a reasonable discussion regarding proportionate levels of security without being able to properly assess potential vulnerabilities and associated risks.


    Immobilisation
    Vehicle immobiliser systems have been developed to protect vehicles from theft. There is a clear need for the security as the risks are very real. Car thefts were far more common prior to their development. Such systems work by only allowing vehicle mobilisation when a key, placed in the ignition switch, is from the unique set authorised to start the vehicle. The following describes a representative immobiliser system and its behaviour during ignition-on and engine-start conditions, just after the car has been unlocked. As we will be discussing potential vulnerabilities, the make and model is not given.

    Component-wise, such systems usually consist of a transponder in the key head, a transponder coil around the ignition switch and an immobilisation control system within either a dedicated immobiliser control module, or another control unit, such as the central electronics module (CEM). The CEM might be hard-wired to an immobiliser indicator in the dashboard or instrument cluster (IC), to indicate the system’s status to the user. The CEM will communicate with the engine control module (ECM) using a CAN bus. Note that, if the CEM is on the medium-speed CAN bus and the ECM on the high-speed CAN bus, then a control module that is connected to both buses, such as the IC, will need to act as a gateway to communications between the two.

    There are usually two stages to the authorisation/start process; the first, a key checking phase, is initiated when the key is placed in the ignition barrel and the second is a start-authorisation phase, instigated when the operator turns on the ignition.
    A typical key checking phase might progress as follows (see Figure 1 for the representative signals): initially the system will be in an immobilised state, indicated by periodic flashing (e.g. once every two seconds) of the immobiliser indicator. When the key is placed in the ignition switch, the CEM energises the transponder coil (e.g. at 125 kHz), which excites the transponder. The transponder responds by transmitting identification and rolling code data to the CEM via an inductive voltage within the transponder coil circuit. The CEM will check the returned data against the stored data to confirm its identity. The CEM might double-check the key identity using the same mechanism.

    The start-authorisation phase proceeds as follows: When the ignition key is turned to position II (ignition on), the ECM detects the ignition supply voltage and sends a start request CAN message to the CEM. If the key is valid, the CEM responds positively, with a code derived from the message contents sent by the ECM. In return, the ECM replies to confirm that the vehicle is in a mobilised state and that it can crank and run the engine. Upon receipt of this confirmation message, the CEM can illuminate the immobiliser indicator (e.g. with a one second confirmation flash) and then turn it off. If the key is invalid, the CEM will respond negatively to the ECM’s start request message, such that the ECM will not crank or start the engine, and the alarm indicator will continue to indicate an immobilised state.


    Insecurity
    The immobiliser’s subsystems could be vulnerable to several types of attack: Key recognition; The key recognition subsystem, consisting of the CEM, transponder coil or and transponder, could be prone to attack if the correct rolling codes could be transmitted in the right way and at the right time. Note that to move the vehicle, the correct mechanical key would need to be in place to remove steering locks etc. Key-less start systems present other sequencing issues (related to direct CAN messaging, described below), which would need to be co-ordinated with the press of the engine start button etc. The biggest vulnerability and simplest way to attack the system is to clone an authorised key.

    Direct access to the CAN bus; If the start-request from the ECM and subsequent immobiliser related messages can be intercepted and the appropriate (algorithmically generated) response codes returned, then the CAN communication system could be used to carry out unauthorised mobilisation of a vehicle. The method would rely on a controllable communication device having a physical connection with the CAN bus. Timing is important (the messages are often expected to be received within a certain time frame) and the genuine responses that would be sent out by the immobiliser controller would need to be mitigated against (e.g. the filtering out of its likely negative response to a start request, that might cause the ECM to immobilise itself).

    Aside from the practical connectivity and the sequencing issues, there is the issue of knowing how to generate the correct response codes to a start request. Although, the codes are observable in an unencrypted network, the relationship between the in and out codes can be extremely difficult to calculate using analytic methods alone and are more likely to be determined from reverse engineering of the control unit’s program files. Aside from the legal implications, the challenge is still great, which is very likely why it has not appeared to have happened.

    Indirect access to the CAN bus; Given the potential difficulties of physically placing a communication device on the CAN bus, an alternative approach is to hijack a device that is already connected. Any internal (software or hardware) system within a connected control module that has access to the controller’s CAN interface might provide a channel through which unauthorised access could be attempted (especially if a vehicle manufacturer has already built-in a remote starting capability).

    It is this type of attack that has been highlighted as a particular concern with the advent of connected vehicles, purportedly presenting hackers with opportunity to remotely control some or all of a vehicle’s functionality. There have been notably few examples of vehicles being hacked in this way and it will be very interesting to see if that changes over the coming years.
    All in all, the challenges needing to be overcome to take advantage of any the three perceived vulnerabilities and to steal a car are great. Quite simply the easiest form of attack is to clone a key. The question is then, what are the motivations for ill-intentioned agents to attack our automobiles and are they likely to want to try to steal a car through attacking the immobiliser system? I’m not sure I’m qualified to answer that.


    Information
    There is a further, related, development that has already dawned within our automotive landscape. Our modern motor vehicles are capable of generating significant volumes of personal data regarding much of our travel and lifestyle habits. This information is hugely valuable. Google’s company worth is colossal and their value is driven purely by their knowledge of our online browsing habits (through the use of their web applications). For the most part, we are not always online. Imagine though, if they could collect a raw feed of data regarding our offline habits, such as those we might create when we travel within our vehicles. How much would the company that had access to that data be worth? With that thought, it is clear why tech firms are falling over themselves to tap into our automotive existences.

    Given that all this valuable data is flying around unencrypted vehicle communication networks (much of it is required by engine, navigation, entertainment and ADAS systems etc.), why in their right minds, would the vehicle manufacturers not want to encrypt that data and keep it to themselves? By doing so they would be able to prevent any third parties, including (coincidentally) aftermarket diagnostic tool manufacturers, from having any access to a vehicle’s CAN bus data, without the vehicle manufacturer’s prior consent.

    Now, in that context, wouldn’t it be convenient if the vehicle manufacturers jumped upon the reports of the hackers’ abilities to put lives at risk, so as to justify the encryption of vehicle networks? Conspiracy theory? Maybe. I am susceptible. I once imagined that the large discrepancy between real-world and quoted fuel efficiency figures could have been indicative of an OE-level distortion of engine test results…


    Further tech info
    http://automotiveanalytics.net/agile-diagnostics




Search

Sign Up

For the latest news and updates from Aftermarket Magazine.


Poll

Where should the next Automechanika show be held?



Facebook


©DFA Media 1999-2018