Mrclopec

Based on my limited experience, there are standard SVM codes for sanctioned retrofits and undocumented one time codes for the more "gray" stuff. This being either one time use codes for software updates or special situations approved by the TAC. If a hardware module was added into the vehicle later on, and a spec-actual were to be run, SVM is gonna bark at you that "module XX is not valid for this vehicle". I was briefly told once that only the master techs are trained specifically on how to address this and that the hardware list can be manually updated to reflect hardware changes in the vehicle without an SVM code.

Two part example:

If coding changes were made in 03-ABS brakes after an auto hold button was installed, then that hardware and coding will not be registered with the server. If after that change the factory tow bar and control module were to be fitted at the dealer, upon running a spec-actual and then the SVM code for conversion, it will update coding in all necessary modules, but then render the auto hold button unusable as it now just reverted back to factory coding plus the changes to reflect trailering equipment installed. To take it a step further, let's say the change in the vehicle wasn't coding and was an addition of a control module such as 20-High Beam Assist. Will the entire SVM process be aborted because of the undocumented control module?

My thoughts on the resolution:

In guided fault, coding can be manually changed in each module if the tech knows the proper binary to change. Is the key to resolving this by manually updating the installation list in the gateway first so the SVM database now has record of the added control modules before SVM conversions are performed? Or is there more to it than that?

PM's are more than welcome here.