No codes, no clues? Have you ever had a car in with a running fault or an issue, and you plugged the diagnostic tool into the OBD socket then read for trouble codes, only to be met with the message ‘no faults stored’?
For many reasons, this confuses technicians and stops them being able to progress with the job. They have no clues or starting point to work from. However, many other tests can be done to find the root cause of the issue. I have worked with many a technician who has been lost after finding a ‘no fault found’ message. I recently had a job where I was able to demonstrate to my colleague how knowing some numbers and how systems work and interlink can help identify what is wrong.
Call-out
The vehicle in question was a 2012 Land Rover Discovery 4. As we specialise in LR we have built up a good reputation in the area for being able to fix them, having also invested in dealer tooling and information. The customer’s first contact with us was via telephone and he explained he had parked the vehicle up outside his house and then having come to it the next day it would not start. The engine would turn over but it would not fire into life. He informed us his local garage had come out for a look and had been unsuccessful in finding the cause and recommended getting the vehicle recovered to us. He asked our call-out charge and asked for us to come and take a look before he organised recovery. This is not my favourite type of job as with limited tooling there is only so much you can do but we agreed to go and take and look and see what we could find.
No fault codes stored
Along with my colleague Jamie we went to the customer’s house that afternoon, taking a scan tool and the tool kit in our work van. Once we arrived we spoke to the customer to gather some information about the problem. He told us no recent work had been carried out on the vehicle and the other garage had done some basic tests on the battery and fuel system where it sat but could not find an issue. I sat in the vehicle and cranked the vehicle to verify the complaint, doing this also allowed a few checks to be done by listening to the sound of the engine cranking. A trained ear can pick up a compression issue, whether it is spinning fast enough or anything mechanical which doesn’t sound correct.
On this vehicle though all sounded ok. I then let Jamie do some checks to see what he could find. As a younger technician he mainly does MOT and general service work, so it was a good opportunity to possible teach him something along the way without the distraction of a busy workshop. After some basic checks he decided to plug in the scan took and see if any fault codes were stored. Upon carrying out a fault code report he was met with the message ‘no fault codes stored’. I then asked him what his thoughts were and where we go next. His reply was “I don’t know?” I am sure this has happened to some of you reading this article, we have all been there.
Live data
I explained to him that live data was a key element here and we should use it to our advantage. We need to look for data relevant to the complaint to rule out what it can’t be, and knowing what the numbers mean will do this quickly. Unfortunately, this takes years of looking at good data, taking notes and memorising it. Luckily for him, I was able to assist. My first checks were to be engine RPM, fuel pressure, immobiliser status, cam/crank synchronisation and a plausibility check of all temperature and pressure sensors to make sure they were in spec. Working through them all with ignition on, then cranking everything looked good so the engine should start but why wouldn’t it? This is where it pays to step back for a moment and evaluate what you know already and what you should do next.
Smoke/air pressure
An engine in its simplest form is an air pump. We know it needs compression, fuel and air to run. With what seemed to be good compression, and from what I had heard, also good data from the scan tool, with limited resources, I decided the next test would be to see if any smoke was being emitted from the tail pipes. This would show if there was any sign of fuel delivery to the engine. With good RPM and fuel pressure, if the ECU is happy, it should be firing the injectors. There was no smoke, however when I felt the tail pipes there was no air pressure whatsoever from either tail pipe. Was this a clue to where the issue may lie?
My first thought was we have a restriction and the engine cannot breathe, so we are missing the air section of the triangle for the engine to run. I then had a good visual inspection of the engine. Knowing the design well, I decided to open the inlet up to atmosphere by removing the map sensor to see if there was any change. If there was a blockage, this test would prove it and allow the engine to run. In this vehicle, the engine is a V6, so it uses a conventional V configuration. To allow air to flow into both intakes of each bank there is what Land Rover call an intake throttle manifold which also houses the MAP sensor, the EGR inlet pipework and a throttle butterfly flap with a rubber hose to direct air from the intercooler into the manifold (fig1). Removing the MAP sensor would allow air to be released if there was an issue from either EGR valve or upstream from the intake i.e. throttle butterfly, failed turbo just to name a few. On removing the sensor and cranking the engine it now fired into life and idled fairly well, this confirmed we had a blockage somewhere manifold side starving the engine of air.
Throttle butterfly flap
Checking the clock, we still had some time left allotted for the call out. I decided as it was easy to remove the intake hose to the intake throttle manifold just to see as a quick test if the issue was before or after. Upon removing the pipework and refitting the map, the engine no would not start, again proving the issue was on the engine side of the pipework. Removing the air intake plenum to the throttle manifold then revealed the issue. The throttle butterfly flap used to strangle the engine of air on shutdown had jammed shut and never reopened as the housing was heavily covered in carbon. This butterfly, when working correctly, should spring back open ready for the next engine start. Questioning the customer and his driving style revealed he mostly done slow speed and town driving and used supermarket fuel, all of which were a contributing factor to the issue as the valve sits closely to the flow of EGR gas from both valves. Forcing the valve open and refitting the components allowed the vehicle to be driven back to the workshop for a repair to be carried out.
Upon the removal of the entire assembly (fig2), it was found the unit would be better to be replaced as cleaning would not remove all of the carbon deposits and could cause the issue to re-occur. The EGR pipework was also removed and cleaned as a preventive measure along with an oil and filter change and the vehicle was returned to the customer.
Further learning
Why were there no fault codes stored you ask? Well on this engine the position off the butterfly flap is monitored and it should have stored a stuck closed fault but this may not be part of the software’s strategy so I am unable to answer why. However, this article shows that if you have an issue and no faults are stored, there are tests you can do to find the issue. So next time you have a scan tool connected, grab for example 10 good live data PIDs and store them then learn them off by heart. Once you have mastered that section move onto some more and soon you will build up a good mental library of what good data should be, which helps massively to fix cars!
Quality street The MOT has gone through change over the past few years. There have been changes in the way the MOT tester and the MOT Centre Manager become eligible to operate a Vehicle Testing Station (VTS) through the qualifications that are available through various national and local training organisations, through to the MOT tester having to manage their own Annual Training and the Annual Assessment.
In combination with the revised MOT Inspection Manual (aligning to the European Directive) being implemented during May 2018, some confusion may exist in this ever changing sector.
The VTS has several people roles that exist, one major role; the Authorised Examiner (AE) or Authorised Examiner Designated Manager (AEDM) being the person having the ultimate responsibility within the business.
A new VTS and those changing their approved status will need an AE/AEDM to hold the Level 3 Award in MOT Test Centre Management prior to the VTS becoming approved by DVSA. Most training providers will deliver the MOT Centre Manager qualification. Part of the qualification is that the person understands how to operate a Quality Management System (QMS) for the purposes of the VTS. This has been identified as an area that most people struggle with within the qualification.
To implement an effective QMS program, the business must initially internally agree the standards that they set. The results are then collected and reported into the QMS. Any problem should have a corrective action. This should be written with an indication the people responsible to carry out the action along with a completion date. If the same problem repeats, then a plan should be developed to improve the situation, and put into action.
The following highlights a few areas that where the QMS needs to focus.
Training
The AE should ensure all staff (employees and contractors) fully understand their responsibilities. This enables them to carry out their job accurately and remain compliant with the necessary requirements.
The MOT tester should ensure that they meet the requirements of the MOT tester Annual Training and Annual Assessment. This year the annual training includes updating their knowledge of the MOT Inspection Manual which was introduced in May 2018. Most MOT testers will be familiar with the revisions and updates to the MOT Inspection Manual, either through specific training prior to the changes or reviewing the Inspection Manual during its implementation stages.
The AE should also ensure that the MOT testers that carry out tests at the VTS, are compliant with the requirements. Failure to do so will result in the MOT tester unable to test vehicles. It should be noted that some MOT testers that have not met the requirements have taken many weeks to become reinstated as an MOT tester as a result of non compliance which could reduce business income.
At present there is no requirement for the MOT Centre Manager to comply with the updating of their MOT knowledge but this could change in the near future.
Procedures
The AE should ensure that everyone involved in the MOT testing process within their business has access to key information, especially focusing on MOT test logs and MOT Test Quality Information (TQI).
TQI can be accessed by both the AE and also the MOT tester, reviewing the MOT test data applicable to their role. The data can indicate both strengths and weaknesses with the MOT testers and the VTS, it is therefore important that this data is regularly reviewed to identify any anomalies within the data and implement an ‘action plan’ to correct any deficiencies, therefore both the MOT tester and the AE have a responsibility in this area.
MOT TQI was highlighted as a requirement for the MOT tester annual training/annual assessment. It is therefore suggested that the MOT Centre Manager also updates their knowledge on Test Quality Information (TQI) and also MOT test logs.
The AE should ensure that the relevant people know procedures for the reporting of equipment defects/problems, the equipment maintenance and any equipment calibration requirements within the specified dates as indicated by the MOT Testing Guide. The AE must ensure that any appropriate records (calibration certificates) are kept and the records are held securely.
The AE should always ensure that the equipment is maintained and calibrated correctly, if a problem is detected (yes things do go wrong) preferable before a breakdown occurs then a clear process should be identified and the rectification of the equipment recorded.
Assurance
The MOT tests which are carried out at the VTS must always have the correct result, the security of data, information and passwords are maintained which will lead to the reduction in risk of MOT fraudulent activity. The protection of data used in the MOT process needs to comply with the General Data Protection Regulation (GDPR) which was also introduced in May 2018 replacing the Data Protect Action (DPA) that previously covered the data. The AE has a duty to ensure this has been complied with.
The process should also include a Quality Control process of the MOT tester to ensure that they produce satisfactory results, and to identify any future weaknesses in their MOT test procedures.
The MOT Testing Guide (updated earlier this year) indicates that a QC check needs to be performed on an MOT tester every two months. Best practice would indicate that the QC process is completed on each MOT tester more frequently such as every month. The QC check should be recorded and kept in-line with the requirements. The QC report should indicate the strengths and weaknesses of each individual (not just indicating the MOT tester is OK) with an ‘action plan’ (further training etc) on how to reduce the weaknesses. The next month Quality Control report should then indicate how the MOT tester has performed against the ‘action plan’. This could help to reduce the VTS risk score, improving MOT tester performance but also increase business performance.
Performing and recording quality control checks within an MOT business can be time consuming and often gets forgotten. The person carrying out the MOT QC must be carried out by an approved DVSA MOT tester. The QC can be achieved within the MOT testing team providing more than one MOT tester is engaged (one MOT Tester is nominated as the QC) or alternatively a service that an outside agency could provide. A Vehicle Testing Station with only one MOT tester could have a reciprocal arrangement with a nearby similar business by carrying out the QC check on each other.
Improvement
An effective QMS used within the VTS should identify any weaknesses that could put the station at risk. Once a weakness has been identified the business should develop an action plan to improve within the area of weakness. This will typically lead to an improvement.
All these points will help to achieve a low VTS risk score. The MOT centre manager should read and understand the various documents provided free by the DVSA on how to carry out a VTS risk assessment and to hopefully reduce the VTS risk score.
The AE can find out more on the qualification by contacting a recognised training provider delivering the MOT Centre Manager Qualification, this will help them better understand the requirements of a Vehicle Testing Station and the various MOT Testing documents and standards associated with MOT testing. Many of these requirements have been revised over the last few years, and it is a requirement for the AE to constantly update their knowledge to remain current. Remember the MOT Testing Guide was revised in early 2018 and many AEs do not have knowledge of the new requirements.
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
