VCDS Limitations when replacing new moules on a MQB Platform

This is just a general question for more experienced users. I have been looking into few retrofits on MQB platform and noticed that there are some real limitations when adding brand new modules into the system. For example, I would like to update door modules to add more functionalities(folding mirrors, ambient light, 360 camera etc) but it appears I would need more advanced VW tools(odis). I have been using VCDS for 9+ years and I feel like there were not as many limitations in the past. Of course security related modules, like immobilizer or instrument clusters always had some limitations.
Anyway, I still love my VCDS and I think its worth every penny but I would like to understand its limitations on a MQB platform. The more I know the less chances to screw up (component protection, bricked modules etc)

Thank you

MQB is a first step to more VAG controlled aftersales. Even ODIS won’t be the solution as parameterization and coding of retrofitted modules online is not possible (at least not in conventional way).

In coming platforms I read somewhere that VAG is introducing encrypted diagnostic connection to the car which will make things even more difficult.

Thank you OEMplusCC for being a long time user of VCDS. We appreciate your support.

Unfortunately, as Downtime has said, the trend is toward more restriction by VAG (and all other OE's).

That does not mean that the Ross-Tech team is not looking for solutions - we are. But like the change that occurred with the UDS/ODX protocol, it took years of hard work by our team to master that. Perhaps some will say we still have not mastered it. UDS first showed up in 2009. Ross-Tech purchased one of the first Audis delivered in the US that had UDS capabilities. Our incredible team has worked constantly to build full implementation. And yet, there is always more to be done.

The changes to parameterization and encryption may preclude aftermarket tools from making the changes we have been used to accomplishing. Ross-Tech does not give up easily and will continue to work toward possible solutions.

Remember too that VCDS was designed primarily as a diagnostic tool. The modifications and tweaks that can be accomplished using the tool were an added benefit provided through the ability to code modules. VCDS was never intended as a modification tool. We expect that diagnostic functions will continue to be available to the aftermarket. The issue will be whether or not module replacement and coding will continue to be available.

We do not know where this all may lead. We do not at present have all answers (will we ever?). Perhaps we can keep this thread open and alive to let others know our findings and our progress.

- Bruce
Director of Operations, Marketing and Sales

Thank you for your responses! This is the exact response I was looking for. I like the tool just want to understand its retrofit limitations on a MQB platform.
One workaround that seems to work on MQB platform is to always use a used module from the same car. Usually that's just plug and play plus some minor coding adaptation changes. Of course this is only true for "less important" modules such as door, trunk modules, headlight modules etc.

^ That is true. That's the most convenient way. Does not help retrofitters though, as getting a used module from a similar car might be very difficult. Also in some cases when you're adding something that model never had, it is then impossible to get an used module.

I wonder what the aftermarket/retrofit/enthusiast portion of a manufacturer's market is worth to said manufacturer?

Some would say it's worth nothing as they don't get a cut, but it does influence a certain portion of the market as to which brand they buy based on what is available to them in the aftermarket/tuning scene.

At least in Australia the tuning/modification scene appears to have moved from Japanese brands (Honda/Subaru/Mitsubishi etc) to German (VAG/BMW/Merc) in the last 15 years or so. (helped also by the closing of all local car manufacturing). Sure partly that's because of the dearth of interesting vehicles being released by the former, but if a manufacturer actively seeks to enable the aftermarket to thrive around their brand that's got to be worth some significant sales?

It seems that the new Supra has been developed with some specific thought towards tuners so it will be interesting to see what happens in that space.

The barrier for entry now for a lot of VAG retrofits is certainly higher and it does make some of them extremely frustrating, however it can also increase the satisfaction level when you do finally get something working.

It would be great if there was one tool 'to rule them all' when it comes to diagnostics and retrofits etc but VCDS remains my most useful and regularly used tool in general.

downtime said:

MQB is a first step to more VAG controlled aftersales. Even ODIS won’t be the solution as parameterization and coding of retrofitted modules online is not possible (at least not in conventional way).

Click to expand...

The lack of a parameter data loading feature seems to be a recurrent complaint from VCDS users. It could help retrofitters a lot if there was something like a "backup/restore data" feature that could allow users to, instead of having to buy a used module, just copying its data from another car or using data posted on some kind of repository similar to the "Reference Scans and Maps of Non-Broken Cars" section of the Forum.

Ronaldo said:

The lack of a parameter data loading feature seems to be a recurrent complaint from VCDS users. It could help retrofitters a lot if there was something like a "backup/restore data" feature that could allow users to, instead of having to buy a used module, just copying its data from another car or using data posted on some kind of repository similar to the "Reference Scans and Maps of Non-Broken Cars" section of the Forum.

Click to expand...

My understanding is that parameterization can be loaded (written), but not read back from most modules.

-Uwe-

In regards to new module parameterization/installing new/used modules. Is there a current a list of MQB platform components that are known to have Component Protection(CP) build in. I'm assuming all main modules would have that, i.e instrument cluster, can gateway, radio etc. However a list of 'Do have' and 'Don't have' modules would be nice!


Side question about component protection, is it possible to "revert" when component protection kicks in? For example, I install a new module and get CP error. Can I reinstall the original module to remove component protection? Or is the only option visit to a dealer? Thanks

Uwe said:

My understanding is that parameterization can be loaded (written), but not read back from most modules.

-Uwe-

Click to expand...

Yes, I haven't seen such feature in other tools either. I was just wondering if reading flash memory or getting a memory dump would be a standard feature of UDS protocol that could be used to get such data.

OEMplusCC said:

In regards to new module parameterization/installing new/used modules. Is there a current a list of MQB platform components that are known to have Component Protection(CP) build in. I'm assuming all main modules would have that, i.e instrument cluster, can gateway, radio etc. However a list of 'Do have' and 'Don't have' modules would be nice!


Side question about component protection, is it possible to "revert" when component protection kicks in? For example, I install a new module and get CP error. Can I reinstall the original module to remove component protection? Or is the only option visit to a dealer? Thanks

Click to expand...

CP matching is for one module only at the time. So no way to remove CP the way you describe.

Main modules to have CP:

ACC radar
Gateway
BCM
Dashboard
MIB unit
SWA3.0 side assist unit

OEMplusCC said:

is it possible to "revert" when component protection kicks in? For example, I install a new module and get CP error. Can I reinstall the original module...

Click to expand...

if you install new part which has CP and CP is flagged as dtc and you reinstall old part, you just need to delete dtc's and that it, it will figure out that everything is as it should be.
ex
you install new gateway just to test it and reinstall old one, just delete dtc's and all is good

OEMplusCC said:

In regards to new module parameterization/installing new/used modules. Is there a current a list of MQB platform components that are known to have Component Protection(CP) build in. I'm assuming all main modules would have that, i.e instrument cluster, can gateway, radio etc. However a list of 'Do have' and 'Don't have' modules would be nice!


Side question about component protection, is it possible to "revert" when component protection kicks in? For example, I install a new module and get CP error. Can I reinstall the original module to remove component protection? Or is the only option visit to a dealer? Thanks

Click to expand...

OEMplusCC: If I can add a not inconsistent response to those that you have already received - the CP "constellation" (isn't that a wonderful descriptor?) which the official language describes as the modules that are captured by Component Protection is a bit like this:



Notice the position of J533 which in the diagram is labelled as the Data bus diagnostic interface, but which VCDS identifies as the CAN Gateway (@ address hex19) - its the CP master which means that it's the module that oversees the entire CP interrogation/response process.

My understanding is that the hex19 module retains a list of the identities of all of the other modules in the CP constellation (including, I believe the car's VIN for the purpose of CP). After ignition switch-on, the CP master interrogates each of the constellation modules for their identity - if the responses are not equivalent to the information contained in the master-list, a CP error is initiated both in the CP master and in the itinerant module.

So, in answer to your second question - as long as the original CAN Gateway is not changed, no CP error will occur if you re-install any of the original constellation modules because when the CP interrogation process re-occurs (post ignition switch-on) the identity of the replaced module(s) will once again align with the data in the master list. This assumes of course that you haven't had the CP master list data changed - as would happen if you removed the CP error through the official FAZIT process.

The other question that you haven't asked is: is it possible avoid CP errors when swapping constellation modules? The answer is YES (well....... it's a type of YES in theory). I've not done this, but theoretically, if it's possible to hot-swap any of the constellation modules after a successful CP challenge/response process has been completed (i.e. post ignition switch-on) - it should be possible to avoid CP errors. Of course this would only apply for the current ignition cycle - once the ignition is switched-off and if the replaced module remains installed, a CP error will occur at the next ignition switch-on

Don

m87a said:

if you install new part which has CP and CP is flagged as dtc and you reinstall old part, you just need to delete dtc's and that it, it will figure out that everything is as it should be.
ex
you install new gateway just to test it and reinstall old one, just delete dtc's and all is good

Click to expand...

Just to clarify this a little bit. As DV52 already very well explained. This works as long as you DO NOT do CP adaptation of the new module to the gateway. That wipes the old module CP info out and requires re-adaptation of the module when you install it back.

So try is ok, but as I'm repeating DV52, as long as you don't change the CP master list everything is reversible.

yep, thats it

downtime said:

Just to clarify this a little bit. As DV52 already very well explained. This works as long as you DO NOT do CP adaptation of the new module to the gateway. That wipes the old module CP info out and requires re-adaptation of the module when you install it back.

Click to expand...

That brings up another question:

Is it uni-directional? I.e. are the IDs of the other modules just stored in the gateway when CP adaptation is done, or is something (like the GW's ID) also written to the other modules?

If it's unidirectional, one should be able to install a new GW, do CP adaptation, and then swap the old GW back in with no CP errors (and thereafter swap the two GWs in and out as much as one pleases with no errors). But if the other modules in the constellation also learn the GW's ID, then this won't work.

GWs are pretty inexpensive and this would be an interesting experiment, no?

-Uwe-

Wiped. Sorry read the post again.

Good question. For other modules this does not work for sure. I’ve tried it. But GW I’ve not tried this way.

If GW is the master, then if it stores the attached modules but where it stores the GW info?

Yes once both gateways have had CP matched to the rest of the vehicle's modules, you can just swap the 2 gateways around at will.

thanks for this kamold, didn't know that

^^^^ hmm........ trying to get my feeble brain around Uwe's scenario. My understanding is that the CP interrogation is a simple one way challenge/response arrangement. As the SSP says (my highlight):

A component protection comparison is usually performed by the diagnostic interface for every terminal 15-ON cycle, and the validity of the installation is checked.

This strongly suggests "unidirectional" - I think (if I understand Uwe's use of the term correctly)

So yes - if a GW has been FAZIT-ed then it will have the correct master list of identities with the rest of constellation modules. Which means that if a number of GWs have been FAZIT-ed on the same car - then ALL the GWs can be swapped with impunity!!

Don

PS: The use of the word "usually" in the SSP extract is interesting. It's a gross generalization, I admit - but German precision in everything doesn't normally allow randomly throwing around words. Does any know under what circumstances the CP interrogation process DOESN'T happen on T15 switch-on?