Vehicle Network Diagnostic Strategies - LIN Case Study

Tim from San Diego Curriculum Developer 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

+19

Dean from Albany

 

Owner
 

Awesome article, thanks for contributing!

+1

Bob from East Longmeadow

 

Diagnostician
 

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

Albin from Leavenworth

 

Diagnostician
 

After all, new = Never Ever Worked :)

+2

Michael from Clinton

 

Mobile Technician
 

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

Brin from Melbourne

 

Diagnostician
 

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

Tim from San Diego

 

Curriculum Developer
 

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 the answers to those questions change the outcome?" Disconnecting the suspect HL allowed the other HL to talk, so the diagnosis is the same either way - the part that brought down the network is bad. That's all a complicated way to say that we have no idea why one LIN circuit affected the other, but it also proves the genius of the isolation method for dead networks. Eliminating the left HL makes everything else work, so there are a lot of undocumented network and module questions that we get to avoid asking. 

+3

Jim from Frederick

 

Curriculum Developer
 

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

Tim from San Diego

 

Curriculum Developer
 

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

Jim from Frederick

 

Curriculum Developer
 

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 Brin's question specifically. The AFS that reported on the health check is actually on CAN Bus 2. It runs the four LIN motor controls for level and sweep as the master. That makes the code reporting through CAN while at least two sections of LIN are down more logical. The interesting thing I see is that only the sweep sections showed comm failure. It would have been interesting to see if the active test for vertices movement worked.

Do you think the wrong headlight unit was installed? Three price for a non AFS equipped unit is much lower.

Anyway, the strategy was valid and the culprit identified. The why always intrigue me.

+3

Tim from San Diego

 

Curriculum Developer
 

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

Scott from Claremont

 

Manager
 

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

0