Debug automotive designs more quickly with CAN-dbc symbolic trigger and decode

The primary measurement tool used to test and debug the physical layer of this serial bus is an oscilloscope. Although CAN bus protocol analysers are commonly used for testing and debugging at a higher level of abstraction, an oscilloscope allows you to monitor the analogue quality – or signal integrity – of the CAN bus' physical layer. The electrical environment in automobiles is naturally harsh, with lots of noise and unexpected transients. Oscilloscopes can capture and show details of those infrequent automotive transients and noise that could be producing CAN bus errors. To assist in synchronising on and identifying specific CAN frames, most current mid and high range oscilloscopes can trigger on and decode the CAN bus in a hexadecimal and/or binary format. This capability is typically an option that you must pay extra for. Fig 1 shows an oscilloscope triggering on and decoding the CAN bus in a hexadecimal format. Note that with the oscilloscope's analogue capture capability, we can see noise as well as various pulse amplitudes. Underneath each captured frame is the time correlated decode trace, telling you the contents of that particular frame. In the upper half of the display is the protocol lister, which shows the contents of all captured frames in a tabular format, similar to a traditional protocol analyser's display.


In this particular example, the scope had been set up to trigger on frame ID 0x201, which correlates to 010 000 0001. The 8byte data field of this particular frame (0x201) shows '0B A8 00 00 27 10 00 00'." What does 0x201 mean? And what does that long data string of hex characters mean? One of the advantages of a CAN protocol analyser is that it can display results at a higher level of abstraction. In other words, it uses human language such as 'speed = 852rpm', not cryptic bits. This can also be achieved on some oscilloscopes. Fig 2 shows the same oscilloscope now triggering on and decoding the bus symbolically. In this example, the oscilloscope was set up to trigger on message 'Brake_Torque', which relates directly to a specific frame ID code (0x211). Instead of a long string of hex characters representing the data field in this frame/message, the oscilloscope displays 'signal' names with signed values, units and/or encoded states, such as 'On', 'Off' and 'Reverse'. In symbolic CAN language, a 'signal' is not the movement of electrons; it typically represents a physical parameter or condition, such as 'Total_Torque: 131.0640k ft/lb'. How does the oscilloscope translate raw bits into symbolic code? All vehicles have associated with each CAN bus and for each particular vehicle a .dbc file, which stands for 'data base CAN'. A .dbc file is an ASCII formatted file with a .dbc extension that defines the CAN network. Fig 3 shows a portion of a simple .dbc file created by Agilent. 'Messages' are simply labels that represent specific frame IDs. For instance, frame ID 2190911837 has been defined to be Message: EngineData in this .dbc file. 'Signals' are more complex. Within Message: EngineData, which consists of 5byte of data (DLC = 5), we have defined three signals labelled 'Fuel', 'Temp' and 'Speed'. Each signal has a specified start bit and length. For example, 'Temp' begins at bit 24 and is 8bit long. Also associated with each defined signal are variable conversion factors, units, min and max warning values and a big Endian/little Endian indicator. Near the bottom of this .dbc file are definitions of state encoded signals. Referring to Message: ABS, signal 'Frnt-R' begins at bit 7 and has a length of 1bit. This means it can only have a value of 0 or 1. Near the bottom of the file, 'Frnt-R' has been defined to be an encoded state where, if the value of the signal is 0, the oscilloscope will display 'unlocked' and 'locked' if the value is 1. Although Agilent created the .dbc file shown in fig 3 using a text editor, there are more efficient ways to do this, especially when creating a .dbc file for more complex automotive CAN systems. The most common tool in use today is Vector's CANdb++. Once a .dbc file is available for the CAN network that you want to test and debug, importing the .dbc file into the oscilloscope is easy: simply store the file on a USB flash drive and then recall the file into oscilloscope. The oscilloscope will then parse the file and save all the important conversion parameters. Note that Agilent's InfiniiVision 4000 X-Series oscilloscope doesn't actually save the entire .dbc file. The oscilloscope's CAN decode and trigger menus will then provide options to turn on symbolic decode and give the ability to trigger on messages and signals on a symbolic level. Fig 4 shows an Agilent oscilloscope triggering on and decoding the built in CAN training signal symbolically using the .dbc file referenced in Fig 3. The lower half of the display shows a zoomed in view of Message: EngineData with signals 'Fuel', 'Temp' and 'Speed'. Since Agilent's InfiniiVision 4000 X-Series oscilloscope is based on an embedded operating system, it is impossible to retrieve the file from the oscilloscope. Even when connected to the internet via the oscilloscope's LAN port, users can't access the internal cpu flash memory system. In addition, you can easily erase the file using the oscilloscope's standard Secure-Erase feature, which is required by many of Agilent's aerospace and defence customers. Since most .dbc files are protected and propriety, this is a critical security tool for the automotive industry. When the Secure-Erase feature is executed, there are no residuals of the .dbc file left in the oscilloscope. There are many tools that automotive engineers use today to test and debug their CAN based designs. The oscilloscope is the primary tool used to test and debug the physical layer of the differential CAN bus. Using an oscilloscope with a CAN trigger and decode option can speed the debugging and testing process. And using oscilloscopes with the additional CAN-dbc symbolic trigger and decode capability will make isolating particular messages and signals for testing even faster and more intuitive. After all, 'EngineData' makes a lot more sense than 0x0296A95D. While oscilloscopes with CAN-dbc symbolic trigger and decode won't replace a CAN protocol analyser and a CAN protocol analyser will not replace an oscilloscope, automotive engineers designing and testing CAN buses in their vehicles and ECUs will typically have both instruments at their disposal for optimum testing. Johnnie Hancock is a product manager with Agilent Technologies' oscilloscope and protocol division.