Software manipulation and how to catch it!

A Mercedes-Benz that Ryan recently encountered provided him with an opportunity to muse on software manipulation

Published:  05 August, 2022

 By Ryan Colley, Elite Automotive Diagnostics

I was recently asked to look at a Mercedes Benz C-Class 250D. This vehicle came from an auction. My customer, a car dealer, asked me to see if I could help him, as all the repairs they had performed to date had failed, with the engine management light still illuminating intermittently. What seemed like a routine task turned into a much deeper diagnosis than should have been required.
    
Before I start my diagnosis process, I always approach the customer to ask if they have any history of the vehicle. Other than their repair attempts, which included a differential pressure sensor and pipework being installed, he knew of no other work that had been performed. This can be problematic because I did not have any information regarding when the fault started to appear. I sought this information because it can often help me repair the vehicle a lot more quickly.
    
I started with a full system scan. If you refer to Fig.1, you will see the scan revealed two fault codes being stored. As you can see, the two codes present were for the exhaust temperature sensor bank 1, sensor 1 and exhaust pressure too high, bank 1.  
    
With any fault related to the diesel particulate filter (DPF), it is critical to address the root cause of the blockage, rather than only fixing the blockage first. Otherwise, the DPF will just block up again. Therefore, it was essential for me to address the exhaust temperature bank 1 sensor 1 fault.
    
By removing the airbox I was able to gain direct access to the sensor and the connector. A few quick tests verified the sensor had good voltage and ground supply. This left me to verify and condemn the sensor as being an open circuit. A new sensor was installed, and the vehicle was then rebuilt.
    
I interrogated the engine ECU and cleared the exhaust temperature sensor fault code. After verifying the sensor was now operational, in live data, I then turned my attention to the DPF being blocked, as indicated by the scan tool PID. Viewing the live data from the differential pressure sensor, which was replaced by the car dealership, I found the backpressure at idle to be 40mbar, and more than 150mbar at 2,500RPM. This indicated a partially blocked DPF. This was then verified using a manometer. This device is used to measure smaller pressures.
    
I suspected this blockage was due to the initial fault of the exhaust gas temperature failing. Therefore, I carried out a clean using JLM's two-stage cleaning solution. This procedure brought the pressure down to 5mbar at idle. After carrying out the clean I reset the DPF adaptation data and monitored the soot accumulation figures on a road test. This confirmed both the adaptation was successful, and that the DPF pressure was within tolerance. However, it was not long before I figured something else was not quite right.

Digging deeper
The DPF pressure sensor reports the pressure-drop across the DPF to the engine computer. The pressure-drop across the DPF is used to calculate the soot load. I could see the DPF pressure sensor operating, however, the engine computer was not calculating soot loading, as this figure stayed at 0% after a 30-mile road test. Please refer to Fig.2.
    
As the soot load is a direct calculation, performed via the engine computer, from the raw data provided by the differential pressure sensor, conformed to be proper, I was concerned about a software-related issue.
    
Using a specialist piece of equipment, I read the engine computer’s software file and checked it against the original software file. I was concerned the ECU’s software had been manipulated to have the DPF and EGR valve deleted, and my suspicions were correct.
    
Now I knew why the soot loading would not increase. Put simply, it was because it was no longer programmed to monitor for this fault. This type of tampering can only be done with intent. Therefore, someone was aware of the software on this vehicle. It is likely it had been tampered with, prior to heading to auction. However, without any previous history of the vehicle, it was difficult to determine that right away.

Proper analysis leads to a proper repair
By using this specialist piece of equipment, I could now flash program an original software file back onto the engine computer, restoring its ability to calculate soot loading, and carry out regeneration. A direct initial change can be seen, as the load level of the DPF was now reading 55%, after the programming was completed. Please refer to Fig.3. This was due to the engine computer using a base value. This changed once the vehicle had been driven and the pressure had been accounted for across the DPF.
    
An extended road test confirmed the fix, as we could now see the soot loading of the DPF. It reacted in direct correlation with the DPF pressure, as we would expect, and no fault-codes were now present.  
    
To summarise, this vehicle had a DPF tampering solution applied to the engine computer, so the computer would not consider the pressures or faults related to the DPF system. However, the so-called solution, which was applied by the previous owner/repairer, was very poor and caused the engine light to be illuminated intermittently.

Related Articles


Facebook


©DFA Media Group
1999-2022
Terms and Conditions