Engine management: Past and future I have long accepted that nothing stands still for long in this industry. Just when you think you have a grasp of the subject something is sure to upset it. Nothing illustrates this more than powertrain diagnostics. Initially this was called fuel injection, and later became engine management. Now I’m afraid it’s even more complex.
I find myself fortunate to have been there at the beginning; Bosch l Jetronic, a 25 pin ECU with if I recall correctly, only 13 pins occupied. No serial diagnostics, no specific tools. So why was I fortunate? Consider my reflection on diagnostics back in the late 1970s and see if they are still applicable today.
Firstly, you had to understand what the system had to achieve, what components it had at its disposal, what role they played and how they interacted within that system.
The next challenge was measurement values; what to expect under a variety of conditions, and what equipment was required to access this information. This all seems so straightforward now, but in those days it was a little like Columbus sailing across the ocean. He knew it was wet, he needed a boat, he knew which way west was, despite this being blasphemy in the eyes of the Pope, and so set off without a clue as to what was out there.
Hardly a logical diagnostic process, however I was writing the rule book and did understand the meaning of the words test don’t guess. So, what’s changed that undermines these basic principles?
Acessibility
With even the most basic of vehicles now relying on a level of technology that makes accessibility almost impossible, OE manufacturers totally forbid any intrusion within the wiring loom and I am sure this explains the why design and manufacture precludes access as a high priority. However, we are brave, and have the Starship Enterprise at our disposal for our journey of discovery.
The problem is one of integration. Systems don’t function in isolation any more, and Columbus now has to map the Americas and Australia at the same time. In order to conduct an accurate assessment of a function it must be in its natural environment and be observed when functioning normally.
Complexity
This is not restricted to a physical state. It also includes software, algorithms, and predictive response, correction or adaptive action. Systems now change their mode of operation based on environmental influences, affected by a very wide range of changing influences. Cylinder select or dynamic stability comes to mind. The driver selects an option from a long list of choices, engine, transmission, and chassis. I used to say that for a function to occur it must have a command followed by response. In today’s world, the command may be a software decision followed by a constantly changing response, stratified and homogenous fuelling, infinitely changing camshaft timing and variable valve lift to name a few.
Test options
Manufacturers are driven by non-intrusive process dictated by guided diagnostics. Pre-determined test plans more often or not end with a pass or fail result, foregoing any data reveal. Is this due to a control of process and cost, or a mistrust in their techs? Actual evaluation of circuits, voltage, current or complex profile is getting ever more difficult. Attachment of gauges in order to measure pressure and flow is often restricted by sealed transit hoses or internal ducting within castings. Serial data has become so much, more powerful and trustworthy, however it does not and will not replace the functions available from an oscilloscope. Specialist mechanical tools and assembly techniques prohibit casual examination, due to cost or the ever more common single fitment parts.
Data extraction
This may lie in a multitude of directions; Physical extraction, camshaft timing, fuel quantity per stroke via the serial port or fuel pressure rise time via the scope. We are forced to monitor not just a physical value, but not how the PCM is adjusting or adapting a value. How do we know the parameters of operation when VMs are removing more and more data in favour of the pass-fail flags from a software automated test profile?
SENT
Rieve gauche, no not a walk along the Left Bank, but a completely new protocol for data and diagnostic transmission. SENT has been developed specifically for automotive applications, rather than being a black-market hooky copy from other engineering developments. SENT stands for single edge nibble transmission, and is a uni-directional out-only data line to the PCM. SENT is essentially a serial interface, used predominantly with throttle position, air mass and temperatures. The basic unit of time is the tick, with a minimum data unit nibble. 0Data transmission speeds over fast or slow channels, where bitrate can also vary: 1xtick= 3us. In essence it is very similar to a single channel can transmission, where the function includes synchronisation, calibration, CRC and checksum.
How am I to challenge the authenticity of data? For example, sensor error may come from power or ground discrepancies, range error, environment influences, calibration error or simply a genuine condition fault. Its design is of course intended to provide an autonomous diagnostic platform via the serial port, excluding any assessment by the techs.
Full circle
What does this mean for the industry? I suspect it will go full circle back to the 1970s, when part swapping was the norm for Christopher Columbus frauds.
Would you like to diagnose more vehicles first time? As we reach March, 2019 is well and truly underway. In fact by the time you read this one third of the year will have whizzed by never to be seen again. Now, I’m not one for New Year’s Resolutions (they’re so last year), but I am the type of chap that likes constant progress when it comes to developing a technician’s career.
There’s so much to be said for small steps taken everyday that on first look appear don’t appear to make a difference, but when gazed back upon over a 12 month period have a staggering affect on your capability to diagnose a vehicle first time, in a timely manner.
Pitter-patter of tiny feet
Small steps are all well and good but where do you start? After all, you don’t know what you don’t know, and you’d like to start your journey to diagnostic success off on the right foot. In this instance I’d start with the end in mind and reverse engineer the outcome you desire. It’s a logical process that works, and can be replicated time and time again in your diagnostic routine.
Your ‘end in mind’ in this instance is a vehicle where the fault no longer exists, that won’t appear back across the threshold of your workshop anytime soon. But how do you guarantee that?
One test to rule them all
I love nothing more than when the delegates working through our training programs have a technical epiphany. This happens at many points on their path of learning, but none more than with bypass testing.
Bypass testing is step nine in Johnny’s diagnostic circle of love (our 15 step routine), and often the key element in the first time fix. The good news for you is that it doesn’t require mythical creatures to forge their magical powers into an object that only one technician can possess. It’s something that every tech can learn, and become a diagnostic wizard.
What is bypass testing?
Quite simply it’s fixing the vehicle before you fix the vehicle. Let me explain.
Wouldn’t it be great if you suspected that a Mass Air Flow sensor was at fault and you could prove that you were right before you fitted a new part, or spoke to the owner of the vehicle. If you could do that then the positive effect it would have on you and the business you work for would blow you away.
Picture this: Your customer has reported that the vehicle is low on power. You’ve diligently questioned them, experienced the problem with them on a road test, and the bought the vehicle into the workshop.
You’ve pulled codes and found none present, followed by taking a look through serial data to hunt for diagnostic clues. It doesn’t take you long to identify that the MAF sensor frequency looks a little low at 1.5 Khz and your fuel trim data is incorrect and making a positive corrections. You’ve seen a bunch of these before and know that 1.85 Khz is a suitable value for this vehicle.
You’re keen to prove that the serial data is leading you in the right direction so confirm the sensor output with your oscilloscope. The oscilloscope frequency mirrors that of the serial tool and your starting to get that warm fuzzy feeling that an you’re onto something.
Steady the buffs
You’ve been close to success before though, only to be thwarted in the final moments so you’re keen not to be caught out twice. You know that documenting the reasons that the MAF output could be incorrect is the way to go, and duly make a list of tests required to confirm your theories.
And the worst MOT tester in the UK is… YOU To save money and raise efficiency, the DVSA has turned to automation. They no longer need an army of Vehicle Examiners wandering from MOT bay to MOT bay. Instead they are collecting data all the time.
Let’s say I am the boss and my business is low on revenue. I beat up the manager and he in turn influences the tester to fail everything coming through the door. The customer is now stuck with no MOT and I have some simple high yield repairs.
Here’s where it gets interesting. The DVSA computer is monitoring individual tester behaviour and looking at averages. The pattern is really easy for a computer at the DVSA to see because it’s just not possible that lots of cars fail on the same items every day. The DVSA’s fix is to target garages where data shows they are hunting for work and send in a VE to crosscheck. He needs only to wait nearby until our tester issues his favourite fails and then arrive to retest the car.
We all, as testers, now have access to our TQI. Lots of testers that I speak to have the sentiment that this data is all rubbish but, here is the rub. The DVSA have a team of very capable data processors looking at this data and writing algorithms that alert them to trends that need investigation.
Take my example of one of my longest-serving testers and allow the DVSA computer to tell me every car that he has tested in the last two weeks of November for the last seven years and add in that we only want to know about cars tested after 4:30pm. We find only one car; a Y reg (2001) BMW 320i convertible, always tested after 5pm with a longest test time of thirty-two minutes and shortest of twenty-seven. Guess what, it’s my guy’s brother-in-law’s car!
For me the horror is that the car has never failed an MOT. It’s also never been in the workshop for any repairs. It looks absolutely dogged out and is on around 180,000 miles. Worst still my guy has never once even advised anything on this car. The VE would assume Barry’s guy is prepared to let things slide at the end of the day, so maybe he plans to visit me after 5pm on a Thursday.
Conflicting vehicle locations
This is a fun story from a close and trusted friend. My guy is at a DVSA IVA check and overhears a conversation by a couple of Vehicle Examiners. It goes like this; VE no.1 is suspicious of an MOT bay offering fraudulent MOT tests. He parks down the road from an MOT bay in Kent and checks which vehicle is logged on and being tested. He takes the registration number of the vehicle in question and calls the DVLA, identifies himself and asks if the vehicle has been seen on the DVLA camera system anywhere in the last half hour. The car was last seen on the M25 twelve minutes ago near Watford in Hertfordshire over 70 miles away.
So, our VE is in Kent and the car is in Hertfordshire. If this works today in a manual sense how long will it be before computers can do this to every single test? Talk about an easy way to stop fraudulent MOTs, just using computers that the government already own.
