Reasoning and diagnostics Part II

In this issue, Barney Donohew explores critical thinking

Published:  13 March, 2017

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.

Within our workshops we constantly face plausible but invalid deductive arguments where the initial statements are true but the conclusion is not guaranteed:

1) The vehicle has faults. Vehicle faults cause DTCs. So, the vehicle has DTCs
2) The vehicle has no DTCs. Vehicle faults cause DTCs. So, the vehicle has no faults

Most of us are wise to the unsound conclusions in these examples, although we have not always been and certainly many of our customers are not.

In diagnostics, deductive arguments are best used when we need to totally justify a conclusion after evaluating a specific system or component test result (e.g. A volt drop above 250mV between these two points on this wire indicates a high resistance fault. The Volt drop is 3 Volts. Therefore, the wire has a high resistance fault between these points.)

How do we justify which test to perform next? We do that by first predicting (making a hypothesis) where the fault might lie by using the observations made within our case (e.g. the symptoms, DTCs and test conclusions). We do not know for sure what the fault might be for any given set of observations (otherwise we would not need diagnostic testing!), so we must make an educated guess as to the probable or possible causes. In these cases, we must use inductive or abductive arguments.

Imagine a vehicle reporting a P0671 DTC (Cylinder no. 1 glow plug circuit) within the engine ECU. There are no other discernible symptoms. Where should we start our diagnostic process and how would we justify it?

Very likely we would decide to test the glow-plug supply voltage and current draw, as our experience tells us that when there is only one glow plug DTC then it is likely that the glow plug itself has gone open circuit. This is an inductive argument; written formally it becomes:

Almost every time I have read just one glow-plug DTC from an engine ECU (specifically either P0671, P0672, P0673 or P0674), the glow plug within the indicated cylinder has been open circuit. This engine ECU is reporting a P0671 DTC. Therefore, the glow plug in cylinder no. 1 is open circuit.

From our prior knowledge, we have extrapolated a conclusion predicting the probable cause of an observed DTC; i.e. we have hypothesised a likely fault within a candidate component. From a perspective of critical-thinking we must bear in mind that the conclusion is not guaranteed to be true. This is a feature of all inductive arguments and we can only assess them relative to the strength of their arguments. Diagnostically, we might use our critical-thinking to weigh-up whether the strength of an inductive argument (amongst other factors) justifies us carrying out a system or component test, but it is unwise to rely on it to entirely accept or reject any hypothesis about what is the fault. The glow-plug example could be classed as a mildly strong argument. A stronger inductive argument might be:

Every time I disconnect a CKP sensor on a running vehicle the engine stops. Therefore, if I disconnect the CKP on this vehicle the engine will stop. [I have yet to come across a vehicle where this has not been the case but there remains the (admittedly very slim) possibility that an engine on some vehicle somewhere in the world at some point in time might continue running with its crank position sensor disconnected].

Essentially the inductive arguments above describe case-based reasoning: "This set of symptoms is like those I observed in a previous case. By analogy, the fault might be caused by..." However, experience can be a double-edged sword: we must be flexible in our reasoning and able to revise our beliefs if necessary; especially in the face of rapidly evolving automotive technology, where any given symptom might be caused by an increasing myriad of potential faults.

Even the most knowledgeable amongst us face situations in which they have only limited experience, understanding or exposure; whether that pertains to an entire system, subsystem or the outset of a case displaying a sparse set of symptoms not previously encountered. It happens to all of us. Regularly. So, if, for example, we find ourselves with a vehicle exhibiting some odd, never seen before, behaviour, what is it we do (after checking all the basics, of course) that gets us to the point of selecting a given system or component test?

Well, we might use parts darts or a brute-force attack (sequentially testing each component one by one) or perhaps something better?! How about if we use theories (hypotheses) that relate component faults to possible symptoms and find the best match of these to the set of observed symptoms to try to predict the likely cause of the problem? If this happens to be what you do, then you are doing the right thing; it is a creative hypothesis forming process known as abductive reasoning and is the most skilful and challenging part of diagnostics. Although it is often summarised as "forming your best guess" it is the only diagnostic strategy that, with practice and knowledge, will allow you to complete the diagnostic process efficiently and effectively.

The hypotheses we form must fit within all existing knowledge regarding system and component behaviour and explain the causes of any possible sparse and/or diverse set of observed symptoms, as well as any new observation added to that set (otherwise a new hypothesis will be required).

Think back to the first time you encountered a P0171 DTC (system too lean), still a (infamously) problematic scenario for many. It is the perfect scenario for an abductive approach: for this symptom, we must consider a set of possible faults and their side-effects, e.g. what faults might cause the engine to sense more air than it is expecting (i.e. air intake leak downstream of air-mass meter; under-reading air mass-meter; faulty oxygen sensor; faulty throttle position actuator or sensor etc.) and relate them to the observed DTC and any other symptoms (e.g. erratic engine idle). Each possible candidate system or component will have its own chance of being the actual fault and we must proceed with our diagnostic testing and systematically prove (using deductive evaluation of system and component test results) where it lies.

Messing with memes
Over the last couple of years, a meme has entered the consciousness of many technicians and readers of Aftermarket Magazine: #testnotguess. Whilst appropriate, with our new knowledge, we see that it could be replaced with an alternative meme to more accurately convey the entire diagnostic process and provide positive instruction: #guessthentest. Given that we must use our imagination to create a hypothesis (which we must test), our imagination is a valuable tool within our diagnostic arsenal (and must be recognised as such); if we view guessing as either an act of induction from our prior knowledge or, the more creative, process of abduction, then the meme neatly encapsulates fault-finding.

Summing up
We can use inductive arguments to justify, with some probability, which potential fault might cause any observed set of symptoms based on our past experiences or knowledge.

We use abductive reasoning when we need to predict a set of symptoms, from their hypothesised relationships to possible component faults, that best match (or cover) an observed set of symptoms. Neither reasoning method guarantees the truth of their conclusions and must be validated.

Related Articles

  • Under pressure 

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

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

  • Part two The good and THE GREAT  

    In part one, we looked at the start of the ‘diagnostic process.’ The first steps were customer questioning, confirming the fault and knowing the system and its function. These help the technician to build the ‘big picture’ necessary to repair the vehicle correctly.
    In this article we will look at the next four steps.

    Step 4: Gather evidence
    It is easy to overlook this step as many technicians think of it as the overall ‘diagnosis.’ However, once the technician understands the system, gathering evidence will provide key information. This step is normally best carried out with the use of test equipment that does not mean the dismantling of systems and components.

    Many technicians have their own favourite tools and equipment but this list can include (but not limited to)
    the following:
    Scan tool – It is always best practice to record the fault codes present, erase the codes, and then recheck. This means codes which reappear are still current. Remember that a fault code will only indicate a fault with a circuit or its function. It is not always the component listed in the fault code that is at fault

    Oscilloscope – An oscilloscope can be used for a multitude of testing/initial measuring without being intrusive. Some oscilloscope equipment suppliers are looking at systems within high voltages hybrid/electric vehicle technology. The waveforms produced by the test equipment can be used when analysing the evidence and may indicate that a fault exists within a system. An understanding of the system being tested will be necessary to understand the information. This may even include performing sums so all those missed maths lessons at school may come back to haunt you. It may take time to become confident analysing the waveforms, so be patient

    Temperature measuring equipment – This can include the use of thermal imaging cameras. Most systems that produce energy/work will also produce some heat. The temperatures produced vary from system to system. Examples include everything from engine misfires to electrical components, as well as air conditioning system components and mechanical components such as brake and hub assemblies. The possibilities are endless and results can be thought provoking.

    Emission equipment – By measuring the end result, an exhaust gas analyser can show you if the engine is functioning correctly. The incorrect emissions emitted from the exhaust help indicate a system fault or a mechanical fault with the engine

    Technical service bulletins – Many vehicle manufacturers produce technical service bulletins (TSBs) that are generated by a central point (usually a technical department) from the information that is gathered from their network of dealers. Some of these may be available to the independent sector either through the VM or through a third party – It’s always worth checking if these exist. They may indicate a common fault that has been reported similar to that the technician is facing. Some test equipment suppliers may provide TSBs as part of a diagnostic tool package

    Software updates – Many vehicle systems are controlled by a ECU. Most vehicle manufacturers are constantly updating system software to overcome various faults/  customer concerns. Simply by updating the software can fix the vehicles problem without any other intervention of repairing a possible fault. This is where having a link to a vehicle manufacturer is vital in repairing the vehicle

    Hints & tips – Most technicians will have a link or access to a vehicle repair forum where they can ask various questions on vehicle faults and may get some indication of which system components are likely to cause a vehicle fault

    Functional checks – Vehicle systems are interlinked and typically share information using a vehicle network. The fault may cause another system to function incorrectly, so it is vitally important that the technician carries out a functional check to see if the reported fault has an effect on another system. By carrying out this check the technician again is building the big picture

    Actuator checks – Most systems today are capable of performing actuator tests. The technician can perform various checks to components to check its operation and if the system ECU can control the component, often reducing the time to the diagnosis, by performing this task the technician can identify whether it is the control signal, wiring or component or it is sensor wiring. This function can be used in conjunction with serial data to see how the system reacts as the component functions

    Serial (live) data – The technician can typically review a vehicle system serial data through a scan tool. Having live data readings to refer to can help you review the data captured. Using actuator checks and viewing the serial data can also help the technician to identify a system fault

    Remember to record all the evidence gathered so it can be analysed during the next step in the diagnosis. We can’t remember everything. If the technician needs to contact a technical helpline they will ask for the actual readings obtained recoding the data gathered will help.

    Step 5: Analyse the evidence
    Analysing evidence gathered during the previous steps can take time. The technician needs to build the big picture from all the evidence gathered during the first few steps. You need to analyse the information gathered, and decide on what information is right and wrong.

    This step may rely on experience as well as knowledge on the product. You should take your time – don’t be hurried. Time spent in the thinking stages of the diagnosis can save time later. Putting pressure on the technician can lead to errors being made. It may be necessary to ask the opinion of other technicians. If the evidence is documented it may be easier to analyse or share between others.

    Step 6: Plan the test routine
    After analysing the evidence gathered it’s now time to start to ‘plan’ the best way to approach to the task or tasks in hand.

    The technician should plan their test routine, decide on what test equipment should they use, what results are they expecting, if the result is good or bad  and which component should they test next.

    Document the plan – this enables you to review decisions made at this stage in the next step. The technician may not always get it right as there may be various routes to test systems/components. The test routine may have to be revisited depending on the results gathered during testing. Documenting the test routine will provide a map.  Also, don’t forget to list the stages, as this is something that could be incorporated into an invoicing structure later.

    The technician should indicate on the routine what readings they expect when they carry out the system testing. This can be generated by their own knowledge/skill or the expected readings may come from vehicle information which they have already sourced. If the information is not known at the time the test routine is planned, then the test routine may highlight what information is required and what test equipment is needed. You shouldn’t be afraid to revisit the plan at any time and ask further questions on which direction the tests should take. If the plan is well documented and the technician becomes stuck at any point, they can pause the process and revisit later. Also the information can then be shared with various helplines that support workshop networks.

    Step 7: System testing
    The technician then follows their pre-determined plan, if it is documented they can record the results of the test(s) as they follow the routine.

    Many technicians tend to go a little off-piste when they get frustrated. Having the routine documented can keep the technician on track and focused on the result. If the routine is followed and the fault cannot be found the technician may have to go back to the analysing the evidence or planning the test routine. The technician shouldn’t be scared of going back a few steps, as I said previously analysing the evidence takes practice and can be time consuming, not to be rushed.
    Summing up
    Remember to follow the process. It is easy to be led off track by various distractions but don’t try to short circuit the process. Some steps may take longer than first thought to accomplish than others. Some distractions may be outside of your control, and it may be necessary to educate others. Practice, practice, practice. Refine the process to fit in with your business and its practices, the business could align its estimating/cost modelling to the process, being able to charge effectively and keeping the customer informed at each stage of the process.

    Coming up...
    In the next article I will be looking at the next four steps which are; Step 8: Conclusion (the root cause), Step 9: Rectify the fault and Step 10: Recheck the system(s). The last article in this series will indicate the final three steps and how to fit them all together in order to become a great technician and perhaps succeed in Top Technician or Top Garage in 2018.

  • Launch UK introduces new X431 Euro Tab 

    Launch UK, has introduced its latest addition to the X-431 range of diagnostic tools, the X-431 Euro Tab. Based on the latest Android technology and Launch vehicle software, the X-431 Euro Tab harnesses Launch’s diagnostic technology, including wide vehicle manufacturer coverage, test functions, dealer level special functions and live data with accurate comparative values. The in-built hi-res camera enables identification of the vehicle model by photographing the licence plate and VIN number, with automatic VIN recognition for most makes and models. It is supplied with a two-year warranty, two-years’ subscription and printer.

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

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