P0301

SVM - Specified/actual comparison

Goal:  This function is designed to ensure all electronic control units installed in the vehicle have the correct part numbers, software versions, coding and parameterization. It will not suggest a control unit software update. During this SVM communication, the part numbers and software versions of the actual control units installed in the vehicle will be sent to the SVM servers. This "actual" data is then compared to the "specified" data in the SVM database for a particular vehicle. The specified data stored on the SVM servers is also referred to as the vehicle "reference".

What an SVM Spec/Actual can do: 

• Document any changes to an electronic control unit's hardware/software part numbers, hardware/software versions, and provide feedback to the user if these changes are accepted or rejected.
• When new parts are installed, it will also calculate coding changes or parameterization¹ changes. If a "hardware replacement suggestion" is given, then a conflict exists with the vehicle reference for that control unit (i.e. SVM expects a different part number or software version for the control unit in question).
• As a rule, SVM will not allow a control unit with the same part number as the original part to be installed if the new part contains an older software revision. In this situation, SVM will return a hardware change suggestion² . In these special cases a new vehicle reference must be manually set by an Audi Product Support Engineer. Please contact the Technical Assistance Center Helpline if you suspect this is the case.

SVM - Direct Input: SVM code for problem related update

Goal:  This function performs any additional functions which cannot be performed with an SVM Spec/Actual. Those functions include the following.

What an SVM code can do: 

• Update the software in a flash-capable control unit if the SVM code³ is valid for the vehicle.
• After the software update is completed, an additional SVM Specified/Actual comparison will be performed to calculate a new coding and/or parameterization and to document all control unit changes as a new reference in the SVM database.
• SVM Codes should not be used to update a control unit without knowing the solution(s) the software update provides. To update control unit software, the technician must first diagnose the condition in the vehicle and find an applicable TSB that provides a valid SVM Code. Randomly trying out multiple SVM Codes wastes time and can sometimes cause conflicts in the SVM database.
• SVM codes can also be used to document manual software updates to the vehicle's systems, as in the case with MMI Software Package (ZUG) updates. These types of updates are performed manually with a CD/DVD/SDcard. An SVM code for an MMI update documents the changes in the SVM database and provides coding and/or parameterization suggestions. It does not perform any software updates.

SVM codes for MMI Software Package (ZUG) updates will only complete successfully if every control unit is updated to the correct software level. This is especially important when a control unit fails/dies during the manual software update process and is then later replaced, but not updated after it is installed. Since the new replacement control unit was not updated the SVM code will fail. The replaced control unit must be updated prior to running the SVM code.

• SVM Exchange (XCHG) Codes can also be used to aid in the installation of new service parts when an SVM spec/actual cannot code or parameterize the replacement control unit, as with all Audi airbag control units.

It is critical to note SVM XCHG codes must be run immediately after a new control unit is installed in the vehicle. If an SVM Spec/Actual is performed instead, it will create an invalid vehicle reference in the SVM database. Once this occurs the SVM XCHG code will not function properly. The only way to resolve this issue is to contact the Technical Assistance Center Helpline to have the vehicle reference manually set. To find the SVM XCHG code, follow the parts bulletin listed in ETKA or search for an applicable Technical Service Bulletin.

SVM - Direct Input: SVM code for vehicle conversion

Goal:  This function allows for a factory approved retrofit of additional control unit(s) using a valid SVM Code for Vehicle Conversion.

• This type of SVM code is documented inside the installation instructions for the control unit and is typically performed as the last installation step. You can identify an SVM code for conversion by the way it is named. They are typically named "050XXX".

SVM - Activations

Goal:  This function is designed to activate additional features or functions within an already installed control unit using an Activation Code and possibly additional PIN codes or Customer codes.

• This function is designed with a security system similar to installing a new operating system on a personal computer. Currently, SVM Activation codes are only being used with navigation map data updates for vehicles with MMI3G/3G+. The customer no longer needs to purchase the Navigation map data. Instead the customer must purchase an "Activation Packet" to unlock the map update in the MMI system. The Activation Packet consists of an Activation Code, Activate Number, and Pin Code. Once the Activation information is used, it becomes permanently tied to the customer's vehicle in the SVM database and cannot be reused with another vehicle.

SVM - communication, checking

Goal:  This function allows the user to check the VAS Tester's SVM online connection status to ensure the tester is communicating with the SVM server.

Tips: 

• ¹Parameterization  refers to data written into the control unit by SVM to customize the software functionality for the specific vehicle or country of operation. It is often referred to as the "calibration data." It is critical the parameterization is executed anytime it is suggested by SVM to ensure the proper functionality of the control unit. Not all control units are parameterized by SVM.
• ² It is also important to note that if there are any "Hardware Change Suggestions" any time when an SVM code is run, a new vehicle "Reference" will NOT be set in the SVM database. This is to prevent any bad data from being documented in the reference. This can create an issue where repeat coding and/or parameterization suggestions are given with all subsequent SVM communications (Spec/Actual or SVM code). All "Hardware Change Suggestions" should be resolved prior to an SVM code being executed! Once the hardware issue is resolved, the SVM code must be run again to set the new reference.
• ³ It is important to note that almost all SVM codes will automatically perform a "Quick Test" to verify if the SVM code is valid for the vehicle prior to performing the software update. This is done to speed up the process and provide immediate feedback to the tech of whether or not SVM will be able to code/parameterize the control unit after the software update is completed. If SVM finds an issue it will indicate the SVM code is valid for the vehicle, but cannot be completed.

Ensure all campaigns and applicable TSBs have been performed

Due to multiple causes for engine misfire, please ensure all campaigns and applicable TSBs have been performed.

Repeat repairs must be carefully addressed to identify the root cause of the concern. Please utilize proper diagnosis steps to ensure that the vehicle is repaired properly and that the concern has been identified, repaired and verified.

Obtain information from the customer

To repair the vehicle correctly, obtain as much information as possible from the customer about the symptoms of the condition and when it occurred.

• In what situation (turning, etc.) does the condition occur?
• Under what environmental conditions (road conditions, weather, temperature, start conditions, etc.) does the condition occur?
• What is the operating situation of the vehicle (activated electrical equipment, gear selection, etc.) when the condition occurs?
• Can the complaint be reproduced?

Workshop procedure

1. Read out the data memory of all engine control modules, and note the environmental conditions on the DTC log.
   1. If there are other entries in addition to combustion misfires, address the other entries before addressing the cylinder misfires.
   2. If DTC P0301 - P0312  (Cyl.1 Misfire Detected - Cyl.12 Misfire Detected) is accompanied by P1250  (Fuel level too low), it is likely the faults occurred due to a low fuel level and not a malfunction of the coils.
   3. Review all applicable TSBs related to cylinder misfires and ECM software improvements before diagnosing the misfire condition. For example, if data shows that a DTC was set during cold start, search ElsaWeb for TSBs related to cold start misfires.
2. Try to duplicate customer complaint based on the environmental conditions at the time the DTC was set. The freeze-frame data gives important indicators for the traceability of the complaint, in particular if it occurs sporadically or at cold start.
3. Review the vehicle repair history for previous misfire or maintenance service that could be related to the current complaint.
4. Observe the requirements of Guided Fault Finding. Perform Guided Fault Finding in full according to the proposed sequence (test plan). Do not skip any steps.
5. Complete Guided Fault Finding correctly and set the readiness code.

   Tip:  This is important to ensure that no subsequent faults occur due to the misfire.

6. In the case of single cylinder misfires:
   1. Before replacing components,  determine whether the misfire migrates to the other cylinders after exchanging the coils. If necessary, perform a test drive to ascertain this.
   2. If the misfire migrates to the cylinder the coil was moved to:
   • Read the DTC memory, print and attach both diagnostic logs (before and after) to the repair order.
   • Return both coils to their original cylinders, and only replace the defective coil.
7. Verify repair under the same environmental conditions (e.g.: engine speed, engine load value, vehicle speed, coolant temperature, intake air temperature, ambient air pressure, voltage at terminal 30, etc.) as noted on the DTC log.

SVM - Specified/actual comparison

Goal:  This function is designed to ensure all electronic control units installed in the vehicle have the correct part numbers, software versions, coding and parameterization. It will not suggest a control unit software update. During this SVM communication, the part numbers and software versions of the actual control units installed in the vehicle will be sent to the SVM servers. This "actual" data is then compared to the "specified" data in the SVM database for a particular vehicle. The specified data stored on the SVM servers is also referred to as the vehicle "reference".

What an SVM Spec/Actual can do: 

• Document any changes to an electronic control unit's hardware/software part numbers, hardware/software versions, and provide feedback to the user if these changes are accepted or rejected.
• When new parts are installed, it will also calculate coding changes or parameterization¹ changes. If a "hardware replacement suggestion" is given, then a conflict exists with the vehicle reference for that control unit (i.e. SVM expects a different part number or software version for the control unit in question).
• As a rule, SVM will not allow a control unit with the same part number as the original part to be installed if the new part contains an older software revision. In this situation, SVM will return a hardware change suggestion² . In these special cases a new vehicle reference must be manually set by an Audi Product Support Engineer. Please contact the Technical Assistance Center Helpline if you suspect this is the case.

SVM - Direct Input: SVM code for problem related update

Goal:  This function performs any additional functions which cannot be performed with an SVM Spec/Actual. Those functions include the following.

What an SVM code can do: 

• Update the software in a flash-capable control unit if the SVM code³ is valid for the vehicle.
• After the software update is completed, an additional SVM Specified/Actual comparison will be performed to calculate a new coding and/or parameterization and to document all control unit changes as a new reference in the SVM database.
• SVM Codes should not be used to update a control unit without knowing the solution(s) the software update provides. To update control unit software, the technician must first diagnose the condition in the vehicle and find an applicable TSB that provides a valid SVM Code. Randomly trying out multiple SVM Codes wastes time and can sometimes cause conflicts in the SVM database.
• SVM codes can also be used to document manual software updates to the vehicle's systems, as in the case with MMI Software Package (ZUG) updates. These types of updates are performed manually with a CD/DVD/SDcard. An SVM code for an MMI update documents the changes in the SVM database and provides coding and/or parameterization suggestions. It does not perform any software updates.

SVM codes for MMI Software Package (ZUG) updates will only complete successfully if every control unit is updated to the correct software level. This is especially important when a control unit fails/dies during the manual software update process and is then later replaced, but not updated after it is installed. Since the new replacement control unit was not updated the SVM code will fail. The replaced control unit must be updated prior to running the SVM code.

• SVM Exchange (XCHG) Codes can also be used to aid in the installation of new service parts when an SVM spec/actual cannot code or parameterize the replacement control unit, as with all Audi airbag control units.

It is critical to note SVM XCHG codes must be run immediately after a new control unit is installed in the vehicle. If an SVM Spec/Actual is performed instead, it will create an invalid vehicle reference in the SVM database. Once this occurs the SVM XCHG code will not function properly. The only way to resolve this issue is to contact the Technical Assistance Center Helpline to have the vehicle reference manually set. To find the SVM XCHG code, follow the parts bulletin listed in ETKA or search for an applicable Technical Service Bulletin.

SVM - Direct Input: SVM code for vehicle conversion

Goal:  This function allows for a factory approved retrofit of additional control unit(s) using a valid SVM Code for Vehicle Conversion.

• This type of SVM code is documented inside the installation instructions for the control unit and is typically performed as the last installation step. You can identify an SVM code for conversion by the way it is named. They are typically named "050XXX".

SVM - Activations

Goal:  This function is designed to activate additional features or functions within an already installed control unit using an Activation Code and possibly additional PIN codes or Customer codes.

• This function is designed with a security system similar to installing a new operating system on a personal computer. Currently, SVM Activation codes are only being used with navigation map data updates for vehicles with MMI3G/3G+. The customer no longer needs to purchase the Navigation map data. Instead the customer must purchase an "Activation Packet" to unlock the map update in the MMI system. The Activation Packet consists of an Activation Code, Activate Number, and Pin Code. Once the Activation information is used, it becomes permanently tied to the customer's vehicle in the SVM database and cannot be reused with another vehicle.

SVM - communication, checking

Goal:  This function allows the user to check the VAS Tester's SVM online connection status to ensure the tester is communicating with the SVM server.

Tips: 

• ¹Parameterization  refers to data written into the control unit by SVM to customize the software functionality for the specific vehicle or country of operation. It is often referred to as the "calibration data." It is critical the parameterization is executed anytime it is suggested by SVM to ensure the proper functionality of the control unit. Not all control units are parameterized by SVM.
• ² It is also important to note that if there are any "Hardware Change Suggestions" any time when an SVM code is run, a new vehicle "Reference" will NOT be set in the SVM database. This is to prevent any bad data from being documented in the reference. This can create an issue where repeat coding and/or parameterization suggestions are given with all subsequent SVM communications (Spec/Actual or SVM code). All "Hardware Change Suggestions" should be resolved prior to an SVM code being executed! Once the hardware issue is resolved, the SVM code must be run again to set the new reference.
• ³ It is important to note that almost all SVM codes will automatically perform a "Quick Test" to verify if the SVM code is valid for the vehicle prior to performing the software update. This is done to speed up the process and provide immediate feedback to the tech of whether or not SVM will be able to code/parameterize the control unit after the software update is completed. If SVM finds an issue it will indicate the SVM code is valid for the vehicle, but cannot be completed.