News

Comprehensive retrofit guide for Volkswagen/Skoda MQB cars in India

20th August 2024, 18:02 by Kanad Kalasur

When I purchased the Slavia, I was sure that someday I would get my hands onto modding the car not for performance, but such retrofits.

BHPian audioholic recently shared this with other enthusiasts.

Introduction:

If you are specifically looking for the park sensor upgrade, skip to post 3. Adding features to VAG Group cars by retrofitting parts into them isnt something new here as well as in International markets. Its fun, the results are pretty convenient, you learn a lot and at the same time blow time and money with high chances of blowing more time and money and face failures as you get hands deeper into this. Many TBHPians have done a lot of such upgrades, and those were the ones who inspired me to even get my hands on a VAG product in the first place..

The MQB cars especially A0IN cars are very country specific and are mostly developed and exported to emerging markets. To make things worse, the Slavia and Kushaq have made its way into lesser markets other than India compared to Taigun and Virtus so there is hardly any international discussions about the same. Compared to the cars sold in developed markets, there are lot of differences at least with electronics and the attention to detail.

When I purchased the Slavia, I was sure that someday I would get my hands onto modding the car not for performance, but such retrofits. It is not because of something I badly miss in the car, but the joy of getting something more from the car without making it look like an aftermarket accessory. Actually these components are not very expensive both as components from China, or OE spares brought from abroad. Having had a career in the automotive systems domain for nearly a decade now, it was time to work on my own car which is actually more simpler than what I do at work. But before continuing any further, I would like to convey my sincere thanks to cardiagn.com for all the service info and wiring diagrams. They have an unbelievable collection of technical data across brands which is just insane. Other acknowledgements will follow as appropriate.

I hope this thread is useful to some people at least, and I sincerely hope you do not brick your car doing something that was not supposed to be done. And please dont ask the warranty question. I cannot answer the same.

MQB Electrical architecture:

Modern vehicles have multiple electronic controllers for various functions. What started decades ago as an Engine Control Module(ECM), a lot of control modules have joined the bandwagon over the years to be generically referred to as an Electronic Control Unit(ECU). Based on their function and complexity, ECUs communicate with each other, as well as offer diagnostics via networks. These networks run across multiple ECUs and enable them to communicate with each other on a common bus. Having Japanese and German cars with me, there is a huge difference in their philosophy including how the electronics and networks are designed. The Japs still rely on old school principles of electric signals being sent as analogue wires, and are having a hard time switching to modern in-vehicle networks out of absolute necessity. The Germans OTOH had in-vehicle networks from a looong time and had CAN bus implemented for most of the components which meant lesser analogue wires that went around from one ECU to another. You can read more about in-vehicle networks here and the excellent VAG self study programme.

There were plenty of benefits in such an arrangement but it came with the issue of increased complexity when diagnosing electrical problems. You could no longer just hold a multi meter against a bunch of wires and troubleshoot why the bulb wouldnt turn on. The latest cars have gigabit ethernet communication and a host of other networks including many different CANs, lots of gateways to switch between networks and dedicated audio-video networks, optical fibre communication etc.

The MQB A0-IN architecture was derived out of the global MQB platform and due to cost reduction needs, some of the complexity was omitted to the extent possible. This also includes the task of reducing excessive electronic controllers in the vehicle and either completely eliminating them or replacing them with simpler units without any networking.

One such example is the door control units. Earlier cars including Polo, Vento etc had a dedicated ECU for each door, which would receive a networked signal from the Body controller and then decode it into individual functions such as windows, electric mirror control, door lock control etc. In the MQB IN, only driver door gets a controller, while the rest of the doors operate with analogue signals from the BCM. Thats how cost reduction has happened. The result - Only driver door gets one touch up down while other doors dont get it. Similarly, the popular function of mirror lowering when you put the car into reverse does not work, since it was a function of the Door controller.

Digging deeper into CAN - The VW way:

See what an entry level car like the VW Polo had in 2002:

Source

There is a network of different ECUs, all connected via CAN networks. For anyone who has studied computer networks, the topology is very comparable to a network with similar number of computers. Each computer can be disconnected from the network without causing severe issues. Similarly, ECUs on the CAN network can be disconnected or added without causing severe issues. By severe, I mean there will be communication between other devices, but the absence of a certain ECU might trigger errors in other ECUs which might have some dependency.

You see different CAN networks here in Red(Drivetrain CAN) and Black(Convenience CAN). They both are connected to the diagnostics plug which also serves as a gateway between the two networks. As the diagram goes, the powertrain related components are all on one network, and the various convenience features are all on another network. There is also data exchange that happens between these networks for various reasons. The climate control unit for example on Convenience CAN wants to interact with the engine control module and vice versa for the operation of the AC and hence, there will be cross CAN communication.

Why separate CAN networks? The answer is easy - to control network traffic and prevent overloading of the CAN due to too many controllers on the same network. The same concept has been carried forward till date, with the addition of networks and introduction of Ethernet based networks for high traffic controllers like ADAS, Infotainment etc since they have data needs that will exceed the capacity of CAN.

Present day VW/Skodas have multiple CAN Bus networks such as:

Powertrain Data Bus
Convenience Data Bus
Extended Data Bus
Infotainment data bus
Suspension Data Bus
Diagnostic Data Bus

Source

They have all evolved due to increasing amount of controllers and the data they exchange. The main difference between these networks is their transmit speed, data packets that are present and various strategies to turn them on or off. The devices on Convenience CAN remain ON for a period of time after the ignition is turned off, whereas the devices on the extended, powertrain buses sleep sooner, mostly as soon after ignition is turned off.

Like how we have a network of switches and servers, in the car there are gateways which serve as the main junction between various CAN networks. The gateway transfers certain messages from one network to another, and will accommodate different data rates. The powertrain CAN runs at a higher speed compared to the convenience CAN. The gateway also contains a list of the various ECUs in the car and tracks their health, startup, shutdown etc and needless to say, a gateway failure can brick your car and leave it stuck in a place without even moving. The list is referred to as Installation list and can be editable to enable and disable communication between those modules.

How this background helps in mods and retrofits

Thanks to global presence of these brands and availability of diagnostic tools, with this info we can add controllers in the car and get them to work with minimal tampering of the existing wiring. Of course we would add a lot of additional components and wiring, but the existing wiring stays intact to the best extent possible and should not affect their functions. The parking sensor installation here is an example, but most of the mods involve accessing one of the CAN networks to be able to enable the new component to talk to the existing components.

We can use diagnostic tools like ODIS, VCDS, OBD11 to enable and disable installations which is shown in this page https://www.ross-tech.com/vcds/tour/...ation-list.php . It is pretty easy and just involves ticking a box or in newer cars editing a drop down list.

Even if a certain ECU is disabled in the gateway, it can still perform and communicate. However, the gateway detects this as a rogue module which was not meant to be there and can throw error codes and even prevent passing messages from this controller to others. If a module is coded in the installation list but is not physically present in the network, again it would cause an error about loss of communication with that module.

Hence, ECUs which are not present in the car can be added, removed and integrated with the rest of the car by tweaking gateway settings AND making some other adaptations on a case to case basis. This is the advanced use of coding tools compared to just changing adaptations or coding on existing components.

Tapping into the CAN network:

CAN communication happens through one pair of wires, CAN Low and CAN High. Modules on the network are connected over the same running CAN bus wires and with junctions. The most popular way of accessing the CAN network is to get a CAN Tap which will prevent any splicing of the wires and issues that can arise out of it. It requires the pins to be de-pinned from the existing connector and that can be done with a de-pinning tool. It is recommended to use the right tools only and not substitutes to prevent any damage to the stock couplers and the pins. Once depinned, the wires are rerouted through this connector which will allow branching of the CAN. One pair of wires go back to the connector where the OE CAN wires were removed from, and another pair will head to the new component. Even in the absence of the new component, the network will work without any issues or errors. So technically this is still a coupler to coupler fitment and we do not have to cut or splice wires.