Today’s vehicles have changed so much that I’m not sure they’re vehicles anymore but computers with wheels! I know they’re still our mode of transportation and will always be vehicles, but the plethora of options and features changes the way we look at vehicle repairs.
So many technicians and shops tell me they wish they could just do the body work and skip all the electronic mumbo jumbo. That, folks, is not our reality anymore. We’re going down the path of vehicle evolution where electronics will become more and more involved in everything we do.
Welding on a quarter panel without considering tolerances for the blind spot module can lead to either a warranty or redo situation on a vehicle with weld-on brackets. The removal and installation (R&I) of simple parts such as a sideview mirror equipped with a camera for surround-view systems may require calibration. This change has been difficult for those of us who have been in the industry for a long time.
Understanding vehicle electronics will be a necessity for all shops in order to not only repair the vehicle but justify the costs. A shop must have documentation to prove why services such as calibration and programming were needed and why there was significant diagnostic time required to find damage to these systems.
Know the Difference
The terms flashing, reflashing, programming and coding are often used interchangeably, but that is a mistake. Many do not realize there is a difference between coding and programming. It is important to understand that all the systems in vehicles are networked together, which is why diagnostic trouble codes (DTCs) have prefixes to identify powertrain, body, chassis and network faults in systems. It’s similar to a company that has to network all the computers, printers and servers together to run the business in one network of communication. What happens when a new device is installed onto that network?
Throughout this article, I’ll be using the terms “primary” and “secondary” to explain differences in modules — the primary module being the module that responds to or controls secondary modules and provides communication to the vehicle’s interconnected systems and the secondary module being a singular module that produces a response or provides an input to the main module.
When a vehicle has been in a crash and components that either respond to an input or perform a specific function are replaced, programming or reflashing of the electronic control unit (ECU) that controls these devices may be needed. When airbags started appearing in all vehicles, reflashing of airbag modules started becoming necessary. The reflashing was the erasing of old calibration files of operation (in this case, the last command being to deploy the airbag or airbags) to new calibration files (when to deploy and, in some vehicles, in accordance with year, make and model of vehicle to operate correctly), basically rearming the system to the parameters of the vehicle being repaired.
There is so much more to this, but in the interest of keeping it in layman’s terms, I will not go into greater depth, as someone way more qualified than me can describe the process much better.
Which Vehicle Manufacturer?
With so many more modules being used now to control vehicle functions, reflashing and reprogramming is becoming more common and will become even more so in the near future. But wait, there’s more.
Newer vehicles have secondary modules that don’t just react to a command from the main control module but provide an input to the main module. Sensors such as radars in blind spot monitoring systems detect a vehicle and send an input to the main module which, in turn, communicates to the module controlling the light in the mirror. Another example is adaptive cruise control radar sensing the vehicle in front and sending a message to the main control module, which now communicates to the main control module controlling the vehicle speed control or braking system. When replaced, these sensors will need to know year, make and model or coding to be able to operate within the correct parameters with the main control module. Situations such as F-150 taillights containing radar will require removing code from the old taillights and coding into the new ones.
In many instances, both the sensor or secondary control module and the main control module will need to be programmed or coded. Vehicle manufacturers are always changing and updating the performance of sensors and modules and the way the vehicle communicates and responds. Replacing a sensor that performs better than the previous version may require altering via coding or programming the files in the main control module. There may also be a communication file that needs to be entered to maintain that only the correct parts are used in the vehicle, which allows improvements in specific functions to be done in the field. When mass changes happen in vehicles, a technical service bulletin (TSB) may be released recommending updates throughout the entire vehicle. Again, each manufacturer has different reasons why engineers require this process. Some are known, some are not. We can only follow the OE service information to correctly complete the job.
Indicators
Experience is a key factor in understanding what needs to be done and diagnosing the issues you may be having. When a part is replaced and programmed but a DTC is still showing, it’s a natural reaction to think that the replaced component is faulty when, in fact, the main module needs programming for the new part. We’ll be seeing this more and more with new headlights that will also require calibrations and improved sensors replacing ones from years ago when the vehicle was manufactured. The industry is learning, but it takes time and patience to gain that experience.
Communication
All this can only be achieved with the proper software and vehicle communication device: in other words, a scan tool or laptop with the correct software to access all these individual modules and a vehicle interface that acts as a gateway between the vehicle and the software being used to access and program the vehicle’s modules — commonly referred to as a J2534 pass-through device. This is the piece that plugs into the OBD port and translates the protocol between the vehicle and software. It’s important to understand that vehicle manufacturers are controlling access to their vehicles and are changing gateway modules constantly. Using software or a J2534 device that is not correct or updated will limit what a shop can do or stop access altogether.
Another factor is subscriptions or access to OE software increasing in use and the cost to end users. This added cost to program or code modules will be a common addition to repairs, especially on newer vehicles — and a challenge for everyone, from shops with OE certifications who are using the OE software in accordance with the certification to other shops using aftermarket equipment.
Another challenge is new vehicles. Aftermarket tool updates can take some time before being able to access the vehicle or all of the modules. This creates challenges for shops, as they may not even realize the software being used cannot see or fix the problem occurring in the vehicle (Note: I am not advocating OE vs. aftermarket, as they all have their place in the repair world). This is all followed by what DTCs are showing in the health systems check or, in layman’s terms, the scan. Knowing how the systems communicate and who they communicate to is needed to correctly diagnose where any problems exist or need to be addressed. Systems not associated with the sensors or system involved in the direct damage resulting from the crash may impact the completion of repairs.
Summary
The repair world is changing and will keep doing so at a pace we’ve never seen before. More change is coming in the world of the drivable computer, and keeping up will be a daunting task for all. You and your shop may be able to do this, and I commend you for that tremendous effort. To others, your partnerships with companies providing these services will be important for the days and years ahead.
