Vehicle Network Diagnostic Strategies - LIN Case Study

Tim Curriculum Developer San Diego, California Posted   Latest   Edited  
Case Study
Network Communications
ATG - Automotive Training Group
2008 Lexus ES350 3.5L (2GRFE) 6-spd (U660E)
B2410 - Headlight Swivel Ecu Lh Communication
B2411 - Headlight Swivel Ecu Rh Communication
Afs Off

Hello everyone,

My name is Tim … and I'm the CEO of … - ATG. Since this is our first submission to Diagnostic Network, I felt compelled to introduce myself and tell you how we at ATG are excited to support this network as a Founding Corporate Partner. We look forward to growing together and helping move the service industry forward, together.

This vehicle came in with a complaint of an illuminated ‘AFS OFF’ lamp. This lamp indicates that the Intelligent Adaptive Front-lighting System is off, and unless there’s a button to do that (there isn’t), it’s time to check high level indicators. Our favorites are the customer interview and the ‘All Codes’ check (called ‘Health Check’ on the OEM Scan Tool).

ADAPTIVE LIGHTING CASE STUDY:

Background

The vehicle came from a body shop where the front bumper, left front fender, and left headlight assembly were replaced due to accident damage. All parts, including the headlight assembly, are aftermarket.

Health Check

The capture below shows current codes B2410 and B2411 set in the AFS system using Toyota TechStream. Other codes were recorded, cleared, and did not come back.

Code Definitions

  • B2410 sets for a fault with ‘Headlight Swivel ECU LH Communication’.
  • B2411 sets for a fault with ‘Headlight Swivel ECU RH Communication’.

Wow! Two bad headlight (AFS) modules! OK, a double failure is unlikely, so it’s time to check the wiring diagram to see how both modules might go offline. The diagram below shows how confusing network wiring diagrams can be and is a good example of the way some manufacturers like Toyota swap terminology like underwear. What we mean is that it takes extra research to learn that:

  • AFS = Headlamp Assembly
  • SML = Swivel Motor LIN
  • SMG & SMB = Ground and power circuits for headlamp assemblies

The Easiest Test

There are a few simple directions to go, including the obvious LIN Lab Scope test. However, the technician decided to disconnect the left headlight and then recheck codes. The logic is that the left headlamp is new, so it’s a variable, and eliminating it makes a lot of sense. Since both headlights have set codes and it’s unlikely that both are bad, a network fault is high on the possible cause list.

Lessons from Disconnection

The capture below shows the codes from another Health Check after the left headlamp was disconnected. Note that both codes are still present, but the B2411 has become a history code. What does that mean? Well, it’s no longer current, which means that the RH Headlight Swivel ECU (OK, the right headlight), is now communicating. The important point is that this proves the network itself is in good condition. One interesting point is that the wiring diagram seems to imply that each LIN leg is independent. In many cases, separate LIN legs really are separate, but the fact that disconnecting the left light gets the right light talking is proof that this fault is affecting the LIN network in the Headlamp Swivel ECU or the ECU itself.

Key Point: This is worth repeating: Isolation is a brilliant network diagnostic strategy. Disconnecting the left headlight allowed the right headlight to communicate, which proves that the network itself is not the fault. The fault must therefore be the new left headlight.

Lab Scope Verification

This diagnosis is done – it’s the left headlight. There are no other possible causes, so a Lab Scope test isn’t necessary. It is, however, interesting! This photo shows the Lab Scope lead back probing the left headlight connector at the SML circuit. For this test, the Lab Scope could also be connected to the SMR circuit at the right headlight (whichever is easiest to access).

The first capture is a trimmed ATS EScope Limited capture showing LIN activity with the left headlight connected (the fault is current). The voltage is stuck at 8 Volts, which is preventing both headlight from talking. The second capture shows normal activity, although zooming in would show a missing response from one module (the left headlight!).

VEHICLE NETWORK DIAGNOSTIC STRATEGIES SEMINAR:

ATG Offers network educational seminars which include many case studies like the one shared above from our new Vehicle Network Diagnostic Strategies seminar.

From Generic Scan Tool communication failures during state emissions tests to complex high speed powertrain and safety system networks, communication problems and U-Codes are becoming a much larger problem every year. This seminar solves that problem by providing known good Lab Scope values, Scan Tool workarounds, and physical testing strategies that avoid the time-consuming ‘resistance test’ path used by most manufacturers.

Layered Diagnostics

Using the ATG High Level approach means that you will start in one place, and then jump around from section to section as needed, taking a different path for every diagnosis. Essentially, each flow chart writes itself as you make simple tests and observations.

For example, if all systems work properly but the Scan Tool won’t communicate, you start with a DLC drag check before putting the Scan Tool itself and the network gateway on the possible cause list, and then proceeding to tests specifically for diagnosing or working around those faults. On the other hand, if there are symptoms along with the lack of communication, then the Scan Tool and DLC are fine, and the diagnostic path adapts to help isolate the open, short, module fault or operating condition responsible.

While the manual and seminar are designed to move in one direction, your diagnostics will be much more dynamic. In fact, each diagnostic path you assemble back in the shop will be unique, leading to much faster isolation of each unique root cause.

Network fault flow charts almost always involve disconnecting multiple circuits to make static measurements. Not only does this take too long, but the end result is often the replacement of modules by default when no previous test pinpoints the fault. At ATG, we’ve solved the modern network diagnostic problem by skipping it in favor of a ‘High Level’ diagnostic approach. Based on simple observations and non-invasive tests, you’ll decide on the most efficient diagnostic path, which may include:

  1. Isolation: Disconnecting modules or junction connectors to restore communications. This allows access to codes and PIDs that further focus your diagnostic path.
  2. Overlay: Jumping around suspected fault areas or modules to establish communication and verify your hunch.
  3. Lab Scope: From tool setup to a collection of good and faulty captures, we’ve got Lab Scope testing completely covered.
  4. Topology Analysis: Using wiring diagrams or Scan Tool functions, you can easily create a map of what does and doesn’t work, leading o a very small and precise possible cause list.
  5. Code Patterns: Multiple code failures present patterns that we can use, including leveraging history and current status changes during isolation and overlay tests.
  6. Other Causes: Other tools and tests are described, including decision-making tips so you know when to (and when not to) check terminal contact, powers, grounds, ignition states, and wake-ups. Options include power and ground circuit load tests, module resets, and bypass strategies.

Jumping Around

Using the ATG High Level approach means that you will start in one place, and then jump around from section to section as needed, taking a different path for every diagnosis. Essentially, each flow chart writes itself as you make simple tests and observations.

For example, if all systems work properly but the Scan Tool won’t communicate, you start with a DLC drag check before putting the Scan Tool itself and the network gateway on the possible cause list, and then proceeding to tests specifically for diagnosing or working around those faults. On the other hand, if there are symptoms along with the lack of communication, then the Scan Tool and DLC are fine, and the diagnostic path adapts to help isolate the open, short, module fault or operating condition responsible.

While the manual and seminar are designed to move in one direction, your diagnostics will be much more dynamic. In fact, each diagnostic path you assemble back in the shop will be unique, leading to much faster isolation of each unique root cause.

We hope you found this article interesting. Please let us know if you have any questions.

Thanks,

Tim

+20
Dean Owner
Albany, New York
Dean Default
 

Awesome article, thanks for contributing!

+1 Default Ð Bounty Awarded
Bob Diagnostician
East Longmeadow, Massachusetts
Bob Default
 

Great case study Tim. I like the logic of disconnecting the "New" part and then retesting. It's such a simple thing but it can yield a lot of information, like it did in this case.

0 Default Ð Bounty Awarded
Albin Diagnostician
Leavenworth, Washington
Albin Default
 

After all, new = Never Ever Worked :)

+2 Default Ð Bounty Awarded
Michael Mobile Technician
Clinton, Utah
Michael Default
 

Tim, Very nice write up. Electrical and Communication faults can really make us run in circles. These simple tests takes the mystery out of the problem.

0 Default Ð Bounty Awarded
Brin Diagnostician
Melbourne, Florida
Brin Default
 

I enjoyed your work as always. Thank you Tim! This is awesome! I get a little more Tim time per year. If the LIN network circuits are truly independent, how could the right side be affected by the left lamp assembly? Is the circuit not truly isolated or is it that the lamp is just confusing the ECU? If that's the case is there any value in knowing how and why this could happen?

+3 Default Ð Bounty Awarded
Tim Curriculum Developer
San Diego, California
Tim Default
 

Hi Brin! Good questions. You can look at a wiring diagram and form the hypothesis that the LIN circuits are independent, but on-car tests like the isolation method used in this case prove that they do affect each other. But is there a hardwired connection between LIN circuits in the module? Or does the module see one LIN short and shut down the other LIN circuit? Maybe a better question is "Can

+3 Default Ð Bounty Awarded
Jim Curriculum Developer
Frederick, Maryland
Jim Default
 

I really like and use the "follow the clues" or jump around method for diagnosis. Understand the system and use clues to set strategy and find the next most logical step. I am curious about something. You mentioned that AFS = Headlight Swivel ECU = Headlight assembly. Is that what was intended?

0 Default Ð Bounty Awarded
Tim Curriculum Developer
San Diego, California
Tim Default
 

Ha! You caught me. We have another HL case study from a Grand Cherokee where the module is the HL assembly, so it looks like I mixed that up. I will get that edited. Thanks!

0 Default Ð Bounty Awarded
Jim Curriculum Developer
Frederick, Maryland
Jim Default
 

Tim, I had no intention of "catching" you. Toyota can appear to switch terms between schematics and systems. Even looking in the RM (Repair Manual) under LIN diagnostics can be confusing until the layout of the information is understood. The RM focuses on the LIN from the main body ECU mostly while there may be several other discreet LIN applications elsewhere like lights.... I was looking at

+3 Default Ð Bounty Awarded
Tim Curriculum Developer
San Diego, California
Tim Default
 

No problem - I would rather be questioned about any errors or confusing bits. Anyway, none of these other variables you or Brin brought up were tested because it was a body shop job and it was their responsibility to replace the HL once it was identified as the source of the LIN fault. Thanks!

0 Default Ð Bounty Awarded
Scott Manager
Claremont, California
Scott Default
 

Hi Tim, editing is now possible as of last night’s release.

0 Default Ð Bounty Awarded