Remember the days when the car-enthused picked their automobiless based on horsepower and styling? Today, with electronics accounting for approximately 25 percent of the value of automobiless, showroom battles are often won (and lost) based on the sophistication of safety and efficiency technologies.

 

Under the hood, all those electronics are linked together with multiple serial buses that interact with the environment and communicate vital information throughout the entire vehicle. The use of embedded devices and the need to communicate information through the vehicle has increased the complexity of vehicle designs and test processes needed to debug and verify these designs. It’s estimated that soon electronics will account for approximately 40 percent of the value of an automobiles. Meaning, it’s more important than ever for electronics engineers working in the automotive industry to become proficient at troubleshooting and debugging the serial bus architectures commonly used in automotive designs.

 

The three serial bus architectures commonly used in automotive design include, Controller Area Network (CAN) for mainstream powertrain communications, Local Interconnected Network (LIN) for lower-cost electronics and FlexRay for higher-end applications. Each bus has certain advantages and disadvantages, as well as common problems that require the ability to decode the various network protocols and time correlate network communication data with external events.

 

While it’s critical to understand each bus individually, along with how they all work together, we’re going to skip the definitions and get right to the insider testing tips. The preferred tool for working with any of the three bus architectures is a mixed signal oscilloscope (MSO), with the ability to support the bus triggering and analysis. Triggering makes it possible to isolate faulty messages, even if they occur very infrequently.

For Example: Consider the need to make timing measurements associated with the latency from when a driver presses the passenger window down switch to when the to when the passenger window actually starts to move. By specifying the ID of the CAN module in the driver’s door as well as the data associated with a “roll the window down” command, you can trigger on the exact data frame you’re looking for.

By simultaneously probing the window down switch on the driver’s door and the motor drive in the passenger’s door this timing measurement now becomes very simple

Recognizing common triggers of all three buses is critical for efficient debugs and troubleshoots. Here is a list of common triggers for CAN, LIN and FlexRay that you should write down:

 

CAN

• Start of Frame – trigger on the SOF field
• Frame Type – choices are Data Frame, Remote Frame, Error Frame, and Overload Frame
• Identifier – trigger on specific 11 or 29 bit identifier values with Read / Write qualification
• Data – trigger on 1-8 bytes of user specified data
• Ack – trigger anytime the receiving device does not provide an acknowledge
• End of Frame – trigger on the EOF field

 

LIN

• Sync – trigger on the sync field
• Identifier – trigger on a specific identifier
• Data – trigger on 1-8 bytes of specific data values or data ranges
• Identifier & Data – trigger on a combination of both identifier and data
• Wakeup Frame – trigger on a wakeup frame
• Sleep Frame – trigger on a sleep frame
• Error – trigger on sync errors, ID parity errors, or checksum errors

 

FlexRay

• Start of Frame – triggers on the trailing edge of the Frame Start Sequence (FSS)
• Indicator Bits – trigger on Normal, Payload, Null, Sync, or Startup frames
• Identifier – trigger on specific Frame IDs or a range of Frame IDs
• Cycle Count – trigger on specific Cycle Count values or a range of Cycle Count values
• Header Fields – trigger on a combination of user specified values in any or all of the header fields including the Indicator Bits, Frame ID, Payload Length, Header CRC, and Cycle Count
• Data – trigger on up to 16 bytes of data. Data window can be offset by a user specified number of bytes in a frame with a very long data payload. Desired data can be specified as a specific value or a range of values
• Identifier and Data – trigger on a combination of frame ID and data
• End of Frame – trigger on static frames, dynamic frames, or all frames
• Error – trigger on a number of different error types including Header CRC errors, Trailer CRC errors, Null frame errors, Sync frame errors, and Startup frame errors

 

If you’d like to read up on those bus definitions and dive deeper into debugging, head over to Test and Measurement World to check out the full article on debugging automotive serial buses, written by Gregory Davis, technical marketing manager at Tektronix. And since we know you want to read even more about test and measurement in the automotive industry, check out this application note on how high amplitude arbitrary/function generator simplifies measurement (it covers semiconductor, scientific and industrial applications too!).

 

 

Image Credit: @Algre - Fotolia