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.

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

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



  • Issues of rotation 

    I received a phone call from another garage: 'We've seen you in the Top Technician magazine and are wondering if you would be interested in looking at an ABS fault for us?' The call went along the usual lines, can the symptoms be recreated? What is the repair history? The vehicle was booked in for me to take a look.

    The car in question was a 2011 Honda
    CR-V, which had been taken as a trade in at a local garage, the fault only occurred after around 50-70 miles of driving, at which point the dash lights up with various warning lights. The vehicle had been prepped and sold to its new owner unaware a fault was present.

    Fault-finding
    After only a few days the fault occurred and the vehicle returned to the garage. They had scan checked the vehicle and the fault code ‘14-1- Left Front Wheel Speed Sensor Failure’ was retrieved. On their visual inspection, it was obvious a new ABS sensor had already been fitted to the N/S/F and clearly not fixed the fault. Was this the reason the vehicle had been traded in? They fitted another ABS sensor to the N/S/F and an extended road test was carried out. The fault reoccurred. This is when I received the phone call; the garage was now suspecting a control unit fault.
        
    My first job was to carry out a visual inspection for anything that was obviously wrong and had possibly been over looked: correct tyre sizes, tyre pressures, tyre tread and excessive wheel bearing play. All appeared ok. The ABS sensors fitted to this vehicle are termed 'Active' meaning they have integrated electronic and are supplied with a voltage from the ABS control unit to operate. The pulse wheel is integrated into the wheel bearing, which on this vehicle makes it not possible to carry out a visual inspection without stripping the hub.

    Endurance testing
    With the vehicle scan checked, all codes recorded and cleared, it was time for the road test. Viewing the live data from all the sensors, they were showing the correct wheel speed readings with no error visible on the N/S/F. The road test was always going to be a long one, fortunately at around 30 miles, the dash lit up with the ABS light and lights for other associated systems; the fault had occurred. On returning to the workshop, the vehicle was rescanned, fault code '14-4 - Left Front Wheel Speed Sensor Failure’ was again present. Again using the live data the sensor was still showing the wheel speed the same as the other three, so whatever was causing the fault was either occurring intermittently or there was not enough detail in the scan tool live data graph display to see the fault. It was time to test the wiring and the sensor output signal for any clues.
        
    Using the oscilloscope, the voltage supply and the ground wire were tested and were good at the time of test. I connected the test lead to the power supply wire and using the AC voltage set to 1V revealed the sensors square wave signal. Then rotating the wheel by hand and comparing the sensors output to one of the other ABS Sensors, again all appeared to be fine. A closer look at the signal was required, zooming in on the signal capture to reveal more detail; it became easier to see something was not quite right with the signal generated by the sensor when the wheel was rotated. With the voltage of the signal remaining constant, a good earth wire and the wheel rotated at a constant speed the signal width became smaller, effectively reporting a faster speed at that instant, not consistent with the actual rotational speed of the wheel. It was difficult to see the error, zooming out of the capture to show more time across the screen it could be seen that this appeared in the signal at regular intervals, although not visible all the time because it was such a slight difference. Using the cursors to measure between the irregular output and counting the oscillations, it was clear that it occurred at exactly the same interval every time. It had to be a physical fault on the pulse wheel.
        
    This meant a new wheel bearing was required. The vehicle was returned to the garage as they wanted to complete the repair, a new wheel bearing was fitted and extended road testing confirmed the vehicle was now fixed.

  • Certifying your future 

    The rate at which the modern car is developing to include new functions based on new technologies is exponential.

    The car owner is often unaware of this, as they see only the ‘HMI’ (human machine interface) that allows them to select and control functions and along with many other electronically controlled ‘things’, the expectation is that ‘it just works’.

    Two key elements are changing with today’s and tomorrow’s cars. Firstly, they are changing into more sophisticated, interactive electronic systems, which require high levels of software compliance. Frequently this can mean that the vehicle needs ‘updating’ which may apply to one system or the complete vehicle. Today this is increasingly conducted by using standardised interface (vehicle communication interfaces – VCI’s) and pass through programming by establishing a direct connection between the vehicle and the vehicle manufacturer’s website. This is now being used even at the level of replacing basic components, such as a battery or engine management system components.

    Secondly, vehicles are increasingly being connected through telematics systems so that the car is becoming part of ‘the internet of things’. This allows remote communication with the vehicle to provide a range of new services to the vehicle owner, driver, or occupants. These broadly fall into two categories – consumer related services, such as internet radio stations, link to e-mails, finding the nearest free parking space and much more, or business related access to in-vehicle data to allow remote monitoring of the status of the vehicle for predictive maintenance, remote diagnostics, vehicle use, pay-as-you-drive insurance etc.

    Increasing isolation
    The in-vehicle E/E architecture is therefore not only increasingly complicated and inter-active, it is more vulnerable to incorrect repair processes. To ensure that this risk is minimised, the vehicle manufacturers are increasingly isolating any possible external connections from the in-vehicle communication buses and electronic control modules. Effectively, today’s 16 pin OBD connector will no longer be directly connected to the CAN Bus and in turn to the ECU(s) but will communicate via a secure in-vehicle gateway. There may also be a new standardised connection which becomes a local wireless connection in the workshop as well as having remote telematics connection, but in both cases, the access to in-vehicle data is no longer directly connected.
        
    Why is this isolation and protection of the in-vehicle systems so critical? Apart from the obvious protection against any malicious attack, there is an increasing safety issue. Thinking longer term, what happens when semi-autonomous cars or fully autonomous cars come into your workshop?
        
    The key question is how to conduct effective repairs on these vehicle systems. At first glance, it may be the basic servicing still needs to be done, but even this will become more difficult, with certain items already requiring electronic control or re-setting. As this develops into more sophisticated systems, the vehicle manufacturer may try and impose more control over who is doing what to ‘their’ vehicles, based on their claim that they have a lifetime responsibility of the functionality of the vehicle and therefore need to know who is doing what where and when. This may lead to an increasing requirement for independent operators to have some form of accreditation to ensure sufficient levels of technical competence before being allowed to work on a vehicle. However, there is also a strong argument in many European countries (the UK included) that this is a market forces issue and that it is the choice of the customer who they trust to repair their vehicle and it is the responsibility of the repairer to be adequately trained and equipped.

    What’s coming?
    Will this market forces attitude still continue when the autonomous vehicle systems are part of the intrinsic safety of the vehicle? This is increasingly becoming the case as these semi or fully autonomous systems take over more control of the vehicle and stop any driver control.
       
    Certainly, anyone attempting any DIY repair will find it much more difficult to access the information or the tools/equipment needed to repair their vehicle, as this will be beyond the knowledge and economic reach of the ‘Sunday morning repairer’, but should DIY repairs even be allowed in the future?

    This raises an interesting argument about who should be allowed to work on a vehicle as the correct repair procedures become increasingly critical. Of course, vehicle manufacturers will continue to have full access to the vehicle and it’s systems, which increasingly will be via remote (telematics) access. This may even compromise the access available to authorised repairers (main dealers), but is seen as a necessary requirement to ensure that the vehicle has been repaired correctly and that the in-vehicle software is still functioning correctly.

    The counter argument is that this also provides unacceptable levels of control and monitoring of the complete independent aftermarket – so what could be a solution?

    Controlling competition
    No one is trying to say that safety and security are not important, but there must be a balance as independent operators will continue to need access to diagnostic, repair, service and maintenance information and continue to offer competitive services to the consumer. The European legislator must protect competition, but this may also come with appropriate controls and this may mean that tomorrow’s technicians will need to demonstrate certain levels of competence, together with an audit trail of the work which has been performed in the event of a vehicle malfunction.

    Independent operators already need high levels of technical competence – necessary for the consumer and the effective operation of their own business, but in the future this may also mean a form of licensing or certification that is required by legislation. If this becomes necessary, then it has to be appropriate, reasonable and proportionate.

    The alternative is that the vehicle manufacturer could become the only choice to diagnose, service and repair the vehicles of tomorrow. I am sure we all agree that it is not what we want or need, so it may be that the increasing technology of tomorrow’s vehicles is the reason that the industry should now embrace change to mirror other safety related industry sectors, such as Gas Safe or NICEIC – qualified, competent and registered. The future is changing and the aftermarket needs to change with it.

    Want to know more?
    Find out how Neil’s consultancy for garage owners can benefit you by visiting xenconsultancy.com.


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