VCDS Limitations when replacing new moules on a MQB Platform

   #1  

OEMplusCC

Verified VCDS User
Verified
Joined
Apr 29, 2019
Messages
42
Reaction score
29
Location
USA
VCDS Serial number
C?ID=160054
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
 
Last edited:
   #2  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
1,941
Reaction score
1,170
Location
Finland
VCDS Serial number
C?ID=280813
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.
 
   #3  

Bruce

Active Member
Staff member
Ross-Tech Employee
Joined
Jan 30, 2014
Messages
1,461
Reaction score
2,690
Location
Near Philadelphia, PA, USA
VCDS Serial number
--------
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
 
   #4  

OEMplusCC

Verified VCDS User
Verified
Joined
Apr 29, 2019
Messages
42
Reaction score
29
Location
USA
VCDS Serial number
C?ID=160054
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.
 
   #5  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
1,941
Reaction score
1,170
Location
Finland
VCDS Serial number
C?ID=280813
^ 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.
 
   #6  

kamold

Verified VCDS User
Verified
Joined
Mar 9, 2015
Messages
413
Reaction score
271
Location
Australia
VCDS Serial number
C?ID=241363
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.
 
   #7  

Ronaldo

Verified VCDS User
Verified
Joined
Feb 13, 2019
Messages
31
Reaction score
46
Location
Brazil
VCDS Serial number
C?ID=357813
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).
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.
 
   #8  

Uwe

Benevolent Dictator
Staff member
Joined
Jan 29, 2014
Messages
30,370
Reaction score
21,669
Location
USA
VCDS Serial number
HC100001
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.
My understanding is that parameterization can be loaded (written), but not read back from most modules.

-Uwe-
 
   #9  

OEMplusCC

Verified VCDS User
Verified
Joined
Apr 29, 2019
Messages
42
Reaction score
29
Location
USA
VCDS Serial number
C?ID=160054
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
 
   #10  

Ronaldo

Verified VCDS User
Verified
Joined
Feb 13, 2019
Messages
31
Reaction score
46
Location
Brazil
VCDS Serial number
C?ID=357813
My understanding is that parameterization can be loaded (written), but not read back from most modules.

-Uwe-
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.
 
   #11  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
1,941
Reaction score
1,170
Location
Finland
VCDS Serial number
C?ID=280813
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
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
 
   #12  

m87a

Verified VCDS User
Verified
Joined
Jan 6, 2015
Messages
582
Reaction score
327
Location
Bosnia and Herzegovina
VCDS Serial number
C?ID=156900
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...
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
 
   #13  

DV52

Verified VCDS User
Verified
Joined
May 16, 2014
Messages
3,694
Reaction score
4,108
Location
Melbourne, Australia
VCDS Serial number
C?ID=194404
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
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
 
Last edited:
   #14  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
1,941
Reaction score
1,170
Location
Finland
VCDS Serial number
C?ID=280813
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
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.
 
  • Like
Reactions: Uwe
   #16  

Uwe

Benevolent Dictator
Staff member
Joined
Jan 29, 2014
Messages
30,370
Reaction score
21,669
Location
USA
VCDS Serial number
HC100001
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.
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-
 
   #17  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
1,941
Reaction score
1,170
Location
Finland
VCDS Serial number
C?ID=280813
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?
 
   #18  

kamold

Verified VCDS User
Verified
Joined
Mar 9, 2015
Messages
413
Reaction score
271
Location
Australia
VCDS Serial number
C?ID=241363
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.
 
   #19  

m87a

Verified VCDS User
Verified
Joined
Jan 6, 2015
Messages
582
Reaction score
327
Location
Bosnia and Herzegovina
VCDS Serial number
C?ID=156900
thanks for this kamold, didn't know that
 
   #20  

DV52

Verified VCDS User
Verified
Joined
May 16, 2014
Messages
3,694
Reaction score
4,108
Location
Melbourne, Australia
VCDS Serial number
C?ID=194404
^^^^ 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?
 
Last edited:
Top