Computers/Controls - Multiple DTC Diagnostics
No: LA418-003Issue: 1
Date: 20 Dec 2006
SECTION: 418-00
Diagnostic Aid for Multiple Diagnostic Trouble Codes
AFFECTED VEHICLE RANGE:
LR3 (LA) VIN: ALL
CONDITION SUMMARY:
UNDERSTANDING ISO 15031 DIAGNOSTIC TROUBLE CODES
Situation: A customer may report a concern that multiple warning lamps and messages are being cascaded on the message center, for example: ABS, followed by DSC, then air suspension, transmission etc. Investigation using diagnostic equipment reveals many diagnostic trouble codes (DTCs) stored in different control modules, including codes with 'P', 'C' and 'U' prefixes. DTCs in excess of fifty have been reported, making the start point for diagnosis difficult to establish. The first DTC logged may not correct the issue.
Proper diagnosis requires an understanding of the DTC structure used for LR3. The structure conforms to an ISO 15031 specification that uses a letter prefix categorizing the DTC into one of four main groups:
^ P = Powertrain
^ B = Body
^ C = Chassis
^ U = Network
NOTE: U1xxx and U2xxx are manufacturer specific, and not specified by the ISO standard.
The "U" network faults are sub-classified into more specific areas:
^ U00xx = Network Electrical
^ U01xx = Network Communication
^ U02xx = Network Communication
^ U03xx = Network Software
^ U04xx = Network Data
The complex nature of the vehicle can cause a cascade effect with a fault codes logging in more than one control module. DTCs with the 'U' prefix can cascade around the vehicle control modules as invalid data, lost communication or control area network (CAN) bus faults can be logged by each module.
^ A fault which is local to a system and only applicable to that system is classed as a 'hard fault' (for example engine sensor 'P' prefix codes and suspension sensor 'C' prefix codes).
^ A hard fault which will result in data for engine torque, engine speed, road speed etc. being invalid will then cascade around the vehicle systems as 'U' codes. The other systems then switch to default mode as designed.
Action: Should a customer express concern regarding cascading warning lamp illumination and or messages refer to the Diagnostic Procedure detailed in this bulletin to help establish the root cause of the logged DTCs.
TOOLS:
WDS/IDS latest diagnostic edition with patches
WARRANTY:
Normal warranty policy and procedures apply.
DIAGNOSTIC EXPLANATION
UNDERSTANDING "CAN AND NETWORK" DIAGNOSTIC TROUBLE CODES
NOTE: When diagnosing multiple Diagnostic Trouble Codes (DTCs) logged in multiple systems ECUs/modules, it is imperative that the complete DTC is recorded for proper diagnosis and repair. Below are two examples of how multiple fault codes can be logged and traced back to their root cause.
LOSS OF COMMUNICATIONS WITH A MODULE (DTC'S U00##-## AND U01##-##)
Each module expects to see CAN messages from one or several other modules on the network. When a module can no longer communicate with another module (it no longer sees CAN messages with the "sender's address" for that module) the receiving module will flag a "loss of comms" fault from the sending module. These are the U00##-## and U01##-## faults. Several receiving modules can store the same DTC that points to a single sending module with a fault. The U00##-## and U01##-## DTC's are the ROOT DTC's indicating that the loss of communications is the basic problem. There may or may not be other P####-##, C####-##, or B####-## DTC's stored in the vehicle ECUs. Diagnosis should be concentrated on the non-communicating ECU's wiring, connections, splices or operational status.
IMPORTANT NOTE: Many diagnostic routines will set Uxxxx-xx DTC's. For more information on this NORMAL circumstance see the attachment "Important Information about Some Network DTCs"
INVALID DATA RECEIVED FROM MODULE (DTC'S U04##-##)
These DTC's do not indicate a "loss of comms" condition. They indicate that the sending module is broadcasting an error token in place of "live and accurate data." These DTC's will be stored in modules that are expecting to receive specific information from other modules on the CAN, but receive the "error message" instead.
Example: The TCM will receive a "Vehicle Speed" signal in the form of a CAN message broadcast from the ABS ECU. ABS reads wheel speed signals from sensors, and then calculates vehicle speed. This message is broadcast by the ABS ECU on the CAN, and may be used by more than one module.
^ The Wheel Speed signals normally read by the ABS ECU are missing, or corrupted, the ABS ECU determines that its inputs are flawed, and that it is no longer capable of determining Vehicle Speed.
^ The ABS ECU will first flag a "hard DTC" such as "C1A95-64 -Generic WSS-Fault: more than one suspected WSS failure occurred"
^ At this point the ABS ECU can no longer provide accurate "Vehicle Speed" data on the CAN, and in place of the "Vehicle Speed" messages on the CAN it will transmit an "error token".
^ When other modules that look for and use the "Vehicle Speed" messages receive the "error token" in place of the "Vehicle Speed" they will register a "U0416-86 Invalid Data Received From Vehicle Dynamics Control Module".
When U04##-## DTCs are present in receiving modules, the U04##-## DTCs are distinct pointers to a problem within the sending module that they refer to. The sending module will in most cases also have stored a hard DTC. (P####-##, C####-##, or B####-##) It is very rare to have an U04##-## DTC without a corresponding P, C, or B code else where in the vehicle. Some U04##-## DTC's will cascade through several modules and the trail may have to be followed back through 2 or more modules to isolate the offending "hard DTC".
DIAGNOSTIC PROCEDURE
PROCEDURE IF MANY 'P' AND 'C' CODES ARE PRESENT ALSO WITH 'U' NETWORK CODES.
NOTE: Most 'P', 'C' and 'B' prefixed DTCs are 'hard faults' which can be rectified, but a small number are due to errors in other systems. Most 'U' codes are due to errors originating from other systems, but a small number are hard faults which can be rectified.
NOTE: In instances where only 'P' or 'C' codes are stored (no 'U' codes), check for other TECHNICAL BULLETIN information issued for the particular DTC or symptom.
NOTE: Do not begin working on the rectification of any DTCs, especially 'U' prefixed codes, without following this procedure.
1. Read the DTCs from ALL control modules and list in groups of 'P', 'C', 'B' and 'U' prefixes.
^ Refer to the Attachment 2 Table and review the 'P' and/or 'C' DTCs against the list in the Table:
^ If a 'P' or 'C' DTC is not listed in the Attachment 2 Table the fault is a 'hard fault' with the system. Perform the following:
^ Correct the fault. It will usually be the root cause of the DTC logging cascade.
^ Diagnose the problem as directed by the diagnostic equipment or using Technical Bulletin information relevant to the code present.
^ Clear all other logged codes.
^ Test the vehicle to confirm the repair.
^ If this action rectifies the complaint, no further action is required.
^ If the 'P' or 'C' DTC is listed in the Attachment 2 Table, it is unlikely to be a 'hard fault' with the related system. Ignore these codes at this point in the diagnosis.
2. Review the 'B' DTCs for instrument pack (IPK), supplementary restraint system (SRS) and the headlamps against the list in the Attachment 2 Table.
^ If a 'B' DTC is not listed in the Attachment 2 Table, the DTC is a 'hard fault' with the system. Perform the following
^ Correct the fault. It will usually be the root cause of the DTC logging cascade.
^ Diagnose the problem as directed by the diagnostic equipment or using Technical Bulletin information relevant to code present.
^ Clear all other logged codes.
^ Test the vehicle to confirm the repair.
^ If this action rectifies the complaint, no further action is required.
^ If the 'B' DTC is listed in the Attachment 2 Table, it is unlikely to be a 'hard fault' with the related system. Ignore these codes f at this point in the diagnosis.
3. Refer to the Attachment 2 Table and review the 'U' DTCs against the list in the Table:
^ If a 'U' DTC is listed in the Attachment 2 Table 1, it is a 'hard fault' with the system. Perform the following:
^ Correct the fault. It will usually be the root cause of the DTC logging cascade.
^ Diagnose the problem as directed by the diagnostic equipment or using Technical Bulletin information relevant to the code present.
^ Clear all other logged codes
^ Test the vehicle to confirm the repair.
^ If this action rectifies the complaint, no further action is required.
^ If a problem remains, ensure a full DTC listing is available for further troubleshooting.
4. If any DTCs have been ignored in steps 1 or 2 above, troubleshoot those DTCs.
ATTACHMENT - 1
IMPORTANT INFORMATION ABOUT SOME NETWORK DTC'S
As discussed in the "Understanding 'CAN and Network' Diagnostic Trouble Codes" section of the procedure, U00##-## and U01##-## DTC will indicate a loss of communications or connectivity between different modules. There are 2 reasons that these DTC's will be present within a vehicle.
1. The vehicle actually has a communications issue, and the indicated module or system requires genuine troubleshooting or investigation. These DTCs may or may not be listed as a "permanent DTC" but should be investigated. There will usually be a customer complaint, and/or MIL illumination associated with true communications problems within the vehicle networks
2. The DTC's were set when performing certain diagnostic procedures using WDS/IDS. These faults are set as a natural and expected result of some diagnostic interrogations. This happens when WDS/IDS places the indicated module into one of several "diagnostic states of operation". These are mostly seen as "temporary" and "pending" DTCs and there often is no MIL or customer complaint prior to beginning the diagnostic session.
When a module is placed into a "diagnostic state", it no longer transmits it's CAN messages that other modules are expecting to see. When this happens, these other modules can set U01##-## DTCs for the module that was placed into its "diagnostic state" by WDS/IDS. In most cases WDS/IDS will warn the technician that DTC's were set within the vehicle, and to perform a DTC clear routine. This is the typical warnings seen after performing transit mode functions, or module programming.
ATTACHMENT 2
TABLE OF FAULT CODES AFFECTING CASCADING MESSAGES AND WARNING LAMPS
NOTE:
This table indicates the following DTC data, applicable to Land Rover LR3 P, C and B codes which are NOT necessarily hard faults, and U codes which ARE hard faults
Help Category Footnote A - Invalid Data
This type of diagnostic trouble code is caused when one or more control modules installed to the vehicle receives invalid data from another control module. As a result of this type of failure the customer will often report unexpected vehicle operation with regard to warning lamp, warning message or audible warning activity.
Invalid data transmitted by a control module is generally caused by an electrical/mechanical problem in that control system, e.g. a faulty wheel speed sensing circuit. The following actions must be taken in order to fully investigate this type of failure:
^ Perform a 'complete vehicle' diagnostic trouble code read (from ALL control modules)
^ Review all stored diagnostic trouble codes in each control module attempting to establish a trend between failures.
^ Investigate and repair all permanent or intermittent diagnostic trouble codes in the order 'P', 'C', 'B' and 'U' unless the diagnostic equipment help text provided for any given fault instructs you to ignore the failure, or the help text refers to Invalid data and/or lost communications.
^ If 'P', 'C', 'B' or 'U' diagnostic trouble code(s) have been investigated and repaired, perform a complete vehicle diagnostic trouble code clear.
^ If any 'P', 'C', 'B' or 'U' diagnostic trouble code either logs or re-logs during the repair confirmation test repeat the steps above as necessary.
^ If no 'P', 'C', 'B' or 'U' diagnostic trouble codes are stored other than those previously instructed to ignore; the following action should be taken:
Help Text Category B - Lost Communications
This type of diagnostic trouble code is caused when one or more control modules does not receive data from another control module when expected. Multiple electrical systems can be affected and when the fault occurs any of the recipient control modules can change behavior and/or alter information being broadcast to other systems on the vehicle, a "cascading" failure.
This type of failure may cause a customer to report unexpected vehicle warning lamp, warning message or audible warning activity. The following actions must be taken in order to fully investigate this failure:
^ Perform a 'complete vehicle' diagnostic trouble code read (from ALL control modules).
^ Review all stored diagnostic trouble codes in each control module attempting to establish a trend between failures, e.g. several control modules report lost communications with one common control module as described above.
^ Investigate and repair all permanent or intermittent diagnostic trouble codes in the order 'P', 'C', 'B' and 'U' unless the diagnostic equipment help text provided for any given fault instructs you to ignore the failure, or the help text refers to Invalid data and/or lost communications.
^ If the customer has reported any problem with vehicle operation with regard to warning lamp, warning message or audible warning activity, an intermittent fault may be present on the vehicle. Based upon the review of stored diagnostic trouble codes, check the integrity of the following areas for each of the control modules identified by a lost communications diagnostic trouble code:
^ Communications network harness and connector.
^ Control module power supply harness and connector.
^ Control module ground supply harness and connector.
Help Text Category C - Lost Communications or Invalid Data
This type of diagnostic trouble code is caused when one or more control modules fitted to the vehicle does not receive data from another control module when expected, or the data received is invalid. Multiple electrical systems can be affected when a failure of this type occurs and the customer will often report unexpected warning lamp, warning message or audible warning activity.
Invalid data transmitted by a control module is generally caused by an electrical error in that control system, for example a faulty wheel speed sensing circuit. The following actions must be taken in order to fully investigate this failure:
^ Perform a 'complete vehicle' diagnostic trouble code read (from ALL control modules).
^ Review all stored diagnostic trouble codes in each control module attempting to establish a trend between failures.
^ Investigate and repair all permanent or intermittent diagnostic trouble codes in the order 'P', 'C', 'B' and 'U' unless the diagnostic equipment help text provided for any given fault instructs you to ignore the failure, or the help text refers to Invalid data and/or lost communications.
^ If 'P', 'C', 'B' or 'U' diagnostic trouble code(s) have been investigated and repaired, perform a complete vehicle diagnostic trouble code clear.
^ If any 'P', 'C', 'B' or 'U' diagnostic trouble code either logs or re-logs during the repair confirmation test repeat the steps above as necessary.
^ If no 'P', 'C', 'B' or 'U' diagnostic trouble codes are stored other than those previously instructed to ignore, the following action should be taken:
Disclaimer