Under pressure

By James Dillon | Published:  18 May, 2017

Even apparently simple problems require thorough investigation if you want to diagnose faults right the first time

We accept a wide range of diagnostic and auto electrical work, primarily from trade customers. This means that some of the jobs we become involved with either come with no history or a nightmare history.

It is very rare to for us to see a straightforward diagnostic job. Vehicles appear with an array of replacement parts, some of these pattern parts are of such poor quality, and having been applied to the vehicle with the consideration of a cluster bomb, are often causing their own microclimate of vehicle running woes.

Healthily sceptical

This working environment means that we are healthily sceptical about everything concerning the vehicle in question. Our approach is one of initial evaluation, whilst tipping a nod to any history which may be available and focussing on the prevalent symptoms. We will then begin gathering data which may be relevant to the symptom. The data will come from a range of activities and tools such as visual inspection, road testing, the five human senses, leak detection, fuel hydrometer, pressure testing, diagnostic trouble codes, serial data stream, gas measurement, voltage and current with the meter and the scope, substitute signal and closed loop computer testing, etc.

Analysing the gathered data occurs upon the execution of each of the tests. Ideally, tests should be run only under the prevailing symptom. A list of good and bad factors is generated as the tests progress. More simple faults may give up their root cause early in the process. Some faults, particularly where poor quality parts have been used, have to be rectified in stages; we may have to undo the human causes before we can see the fault's original cause.

In curing a vehicle symptom, the data will provide the evidence as to the root cause. Sometimes the data will confirm a part or subsystem is definitely not at fault (eliminated), sometimes the data can infer that a part or subsystem may be at fault (suspected) and sometimes the data will confirm definitively that a specific part is at fault (confirmed). As the data gathering proceeds, the potential root causes are classified and the list of suspects shrinks from everything to just one thing. The skill in the job is defining the best diagnostic path to eliminate the suspects in the most efficient manner.

Lack of symptoms

A recent case which came to us with a lack of performance was a 2013 Renault Master fitted with a 2.3 dCi engine which was controlled by Bosch EDC 17 engine management system. Out of the blue the vehicle would just not rev past 3200rpm. The road-test gave an indication of fuel starvation or a lack of boost and the vehicle did not pull at all well during road test. Other clues (shown by a lack of symptoms) included that the vehicle started on the button and ran smoothly. There were no signs of exhaust smoke at idle. When the vehicle got into its upper rev range, it did produce a little blue/grey smoke though. The lack of symptoms data is as useful in diagnostics as the presence of symptoms data. For instance, if the EGR was in trouble, we would expect there to be rough idle and smoke; as these symptoms were absent, we could infer that the EGR was probably not in trouble.

An examination of the vehicle's DTCs showed the following codes, P2263 Boost Pressure Too Low (perm) and three glow plug open circuit faults (int). This vehicle had under bonnet stickers that indicated that it was fitted with a DPF and a quick visual inspection showed that there was indeed a DPF can in the exhaust and the two obligatory pressure pipes rising forth. My initial thoughts when seeing a DPF vehicle with glow plug faults and a lack of boost were to consider a blocked DPF as a potential suspect, however, a distinct lack of DPF blocked codes made me cautious about my suspicion. The vehicle did arrive from another repairer, so any codes relating to DPF issues may have been deleted previously and the van had not been driven far enough to complete a drive cycle. Sometimes knowing what we do not know can provide enlightenment and prevent distraction in the diagnostic process.

Substitute values

My next step was to take a look at the live data stream, as the symptom was ever present, the data stream would likely garner some clues as to the root cause of the issue. Choosing the parameter values carefully was probably the quickest way to build a picture of what was actually happening with the vehicle. I attempted to match the symptoms with relevant data parameters. I chose Accelerator Pedal Position, Rail Pressure, Boost Pressure, Boost Control Solenoid Command, Air Flow and DPF Pressure. A word to the wise regarding live data: There is a possibility of the engine computer using default or substitute vales in case of a problem with a component. This means that the values which appear on the scan tool may have been substituted by the engine computer.

When the engine computer calculates the fuel demand (which is then used to set the fuel quantity), it relies on several data points to look up the correct value for the operating conditions. For example, some of the values used may be engine temperature, mass air flow, boost pressure, throttle position. If one of these data values is incorrect, perhaps because the sensor has failed, the lookup value may be quite a way from what is actually required to make a good calculation, and the vehicle may run very badly or not at all. To reduce the impact of failed inputs, the engine computer uses a back-up or substitute value of data points for inputs that are out of range. This substitute behaviour is so that the engine computer can continue to run with limited inputs; the substitute values mean that although the calculation is off, it is still close enough to allow the vehicle to continue to run.


This substitution situation may mislead the unwary technician. In order that the technician gets a proper view of what is going on, the best policy is to verify scan tool data by measuring the physical output voltage from any suspect sensors. Obviously, this is more time consuming than simply observing the scan tool data, however, the payback is that the measured voltage is a true, raw, unadulterated indication of what is actually happening at the sensor. The Diagnostic Assistance software from Auto-Solve is a great tool in helping technicians understand raw sensor values to enable the performance of such tests.

Looking at the array of data, what is the weirdest parameter value? For me it was the parameter which supported the DTC: The Boost Pressure had dropped below atmospheric pressure. This indicated that either the sensor/wiring/ECU was bad, or that there was a vacuum in the intake manifold. This vehicle had a throttle valve. The symptom fitted with the data; the engine did feel as if it was being choked. But what was the cause? Could the DPF do this? No, it could cause a lack of boost, but it could not cause a vacuum in the manifold. The DPF data indicated that the DPF filter was not blocked.

Next step

So, the next step was to check out the boost pressure sensor voltage to prove its function. The sensor was easy to access and passed the voltage check, KOEO. I then used a sensor simulator to check the feedback logic of the engine computer and the sensor wiring. I sent a varying analogue voltage onto the sensor pin and assessed the live data on the scan tool and the multimeter in synch, which were shown as expected. Next up was a dynamic test. I ran the vehicle and took the revs up to the bad zone; the boost sensor voltage dipped under the KOEO value.

Root cause

Now to consider reasons for a restriction in the intake: A faulty throttle valve, blocked air intake, blocked air filter, blocked intercooler, broken/stuck compressor wheel or a collapsing intake pipe. I pulled the air filter and checked the panel filter and the air intake which were all sound and without blockages. I removed the pipe from the inlet manifold and checked the position of the throttle valve; it opened and closed as designed. I also measured the throttle valve feedback signal so that I could see the valve's position when the pipes were refitted. The turbo spun freely and was without significant play. I reassembled the pipework and then ran the vehicle at idle and measured the throttle feedback, it was open. I used a heavy foot to operate the throttle remotely so that the engine was in the "zone" and I returned to the engine bay. I looked and felt the intake pipework and I could see one of the lower intake pipes to the intercooler was collapsing (figure 1). The throttle was definitely open and the intake system was clear between the filter and the inlet manifold, a weak walled pipe had to be the cause of the problem. A relatively simple problem, the diagnosis of which was made simpler by a robust process.


Although the data provided a good clue to the root cause, the additional checks and tests provide surety in the quality of the diagnosis. It was possible to have diagnosed and replaced the pipe without any of the additional checks, but doing this would not have guaranteed a fix, as there could have been a secondary issue causing the vacuum. Using a combination of knowledge, data and a critical analytical process led to the root cause being determined, right-first-time. I was being paid to do a professional job and I could happily guarantee a fix and not a parts darts approach.

Related Articles

  • Reasoning and diagnostics Part II 

    We began this journey last issue, so to recap: We need solid reasoning skills to carry out effective diagnostics; persistently good decision making doesn't happen by chance. Possibly out of convenience these skills are often underestimated and undervalued by people, both in and out of the trade. We must raise awareness of the discipline and precision of thought necessary for logical and critical thinking: so we can be better rewarded for our efforts; and to make sure they are consistently and properly applied.

    Reasoning, arguments and hypotheses
    We covered some fundamentals in my last article: we explain our reasoning using arguments, which contain statements supporting a conclusion; one type of argument, a deductive argument, should guarantee the truth of its conclusion (if it is sound); however, we need to use critical-thinking to check this, by making sure i) there are no other possible conclusions (which makes it a valid argument) and ii) the supporting statements are true.

  • DENSO launches new sensors for Toyota and Lexus  

    DENSO has added 10 camshaft and crankshaft position sensors to its range. The five new crankshaft position sensors have 129 applications across the Toyota and Lexus range incorporating both past and present vehicle models. The eight new camshaft position sensors have 119 applications across the same vehicle pool.

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

    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.

  • 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 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.

    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.

    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.

    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

Most read content


Sign Up

For the latest news and updates from Aftermarket Magazine.


Where should the next Automechanika show be held?


Click here to submit an event


©DFA Media 1999-2016