Simcenter Testing Solutions Simcenter Testlab: Tips for Trouble-free CAN Bus Operation

Finding out the exact cause of why the CAN data is not being read requires troubleshooting the physical hardware connections and corresponding software settings.
 

 
This article serves as a quick guide for troubleshooting CAN data.  The article contains both hardware and software sections to help ensure smooth acquisition of CAN bus data in Simcenter Testlab.   

Article contents: 
1. Terminology 
2. CAN Bus and Simcenter Testlab Overview 
  2.1 Vehicle CAN Bus Via OBD Port 
  2.2 Vehicle CAN Bus Tapping 
  2.3 Digital Sensors 
3. External Factors 
   3.1 CAN Bus On? 
   3.2 Unlock CAN Bus  
   3.3 Sensors Broken? 
4. Physical Hardware Connections 
   4.1 CAN Connectors 
   4.2 Gateway Location 
   4.2 Cables 
   4.3 Simcenter SCADAS CAN Cards and Status Lights 
      4.3.1 Simcenter SCADAS SYSCON Controller 
      4.3.2 Simcenter SCADAS CN-4 Card 
      4.3.3 SCADAS RS
      4.3.4 Simcenter SCADAS Lights
5. CAN Bus Hardware Terminators 
   5.1 Terminator Overview 
   5.2 Vehicle CAN Bus Termination
   5.3 Digital Sensor CAN Bus Termination 
   5.4 Digital Sensor Termination Example: Thermocouple 
6. Software: Configuration Files and CAN Parameters 
   6.1 Configuration Files: DBC and ARXML 
   6.2 CAN FD versus CAN Bus 
   6.3 Baud Rate
   6.4 CAN Sample Point
   6.5 CAN FD: Data Rate and Data Sample Point
   6.6 CAN Acknowledge: Active versus Passive 
7. Decoding Tips 
   7.1 RDDF File 
   7.2 Reading a RDDF (Raw CAN) File
      7.2.1 RDDF to ASCII Standalone Converter
      7.2.2 RDDF to ASCII in Simcenter Testlab Neo
   7.3 Validate CAN Traffic Via RDDF ASCII File
      7.3.1 Empty RDDF ASCII File
      7.3.2 Populated RDDF ASCII File
   7.4 Checking Messages in RDDF ASCII File versus DBC/ARXML 
   7.5 Message Request: OBD-II and  SAE J1939 

1. Terminology

List of some acronyms and other abbreviations used in this article: 

2. CAN Bus and Simcenter Testlab Overview  

CAN bus (Controller Area Network) is a cabling and communication system that is used to connect multiple devices together and allow them to communicate with each other. 

CAN bus is commonly used in vehicles to communicate between Electronic Control Units (ECUs).  CAN bus is also often used with digital sensor devices as well (see Figure 2): 
 

 

All the communication between the devices is done digitally.  This allows a single wire to be used to carry multiple signals: 

Compared to analog signals, the setup and measurement of CAN bus signals is different.  With analog signals, an incorrectly powered transducer might show a partial response, even though it is not functioning fully correctly.  In a digital CAN bus signal, it is all or nothing.  Unless all the settings are correct, no signal will appear. 

More information on the setup and use of CAN signals in Simcenter Testlab here: CAN Bus Measurements

There are several physical configurations or layouts for acquiring data via CAN bus data.  These are explained in the next sections. 

2.1 Vehicle CAN Bus Via OBD Port 

CAN bus signals are sometimes accessible over an OBD port on a vehicle.  The OBD port is convenient because it can be programmed to provide a single connector to read all required CAN bus information. 

OBD-II is a standard protocol which runs on top of the CAN bus (physical and data layer) protocol and provides digital data over the OBD port in vehicles featuring internal combustion engines.  The OBD-II standard protocol is used for measuring legislated signals for emissions testing through the OBD port, but sometimes a OBD port serves the dual purpose of providing not only the legislated signals, but also the CAN bus signals if in a vehicle is programmed accordingly.

The OBD port on many vehicles is often located under the dashboard. Example is shown in Figure 3.  
 

To read data from a CAN bus, a file that contains a list of the signals and how to read them is required.  Two of the most common CAN bus files used are DBC (*.dbc) files and ARXML (*.arxml) files.  These files are specific to a vehicle and its powertrain. 

OBD-II signals used in emission testing are a subset of all signals present on the communication bus of a vehicle.  If it is desirable to read only the OBD-II legislated signals, they can be read without a vehicle specific file: No more tach! Use OBDII to get Engine and Vehicle Speed...

It is not required that CAN bus signals are available through the OBD-II port.  If this is the case, alternative methods can be used to connect to the CAN network as explained in the next section. 

2.2 Vehicle CAN Bus Tapping 

If the CAN bus signals are not present or available through an OBD-II port, then they must be accessed in a different manner.  Instead of a single connection, each CAN bus “sub” network (powertrain, body, chassis, etc) might require a different connection.  

It is possible there is no connection at all, so it may be necessary to tap into the CAN bus cable to read it as shown in Figure 4:
 

Each sub-network can carry different signals (and some common signals). Each network might have its own connector (usually a DB9 connector).  If not, it may be necessary to tap into the cable and add a connector manually. 

2.3 Digital Sensors 

There are many different types of sensors (inertial, temperature, pressure, force, etc) that utilize a CAN bus output to carry the sensor signals as shown in Figure 5: 
 

When using a Simcenter SCADAS, digital sensors that use CAN bus are convenient.  The CAN input on the controller card can be used rather than occupying a SCADAS slot to perform measurements.  For example, 16 thermocouples can be measured via a single CAN input rather than using two slots with a T8A Thermocouple card. 

3. External Factors 

When recording signals with CAN bus, there are few key items to check if no signals are present: 

3.1 CAN Bus On? 

If the vehicle or digital sensors are not powered and turned on, no signals will be present on the CAN bus. 

3.2 Unlock CAN Bus  

In some CAN bus systems, the signals are protected and unable to be read unless a specific key (electronic file) is used to unlock them.  The key is managed by a seed-key system. 

The basic idea of a seed-key system is that the Electronic Control Unit (ECU) provides a seed — a short string of byte values — and the tool is required to transform that seed into a key using a secret algorithm. The ECU applies the same algorithm internally, and compares the key value given by the tool to its own value. If the two agree, the tool is assumed to “know” the secret algorithm, and access is authorized. 

Even after unlocking the bus, additional protections might deny access to the CAN bus after a certain number of hours of operations, or after a certain amount of distance traveled. This would require another seed-key operation to unlock the bus. 

3.3 Sensors Broken? 

Of course, if any of the sensors are broken, they will need to be fixed. 

4. Physical Hardware Connections

To record CAN bus signals, the proper physical connectors, cables, and terminators must be used and connected. 

4.1 CAN Connectors 

The connector on the CAN device is usually a 9-pin serial connector as shown in Figure 6 below: Pins 2, 3, and 7 are standard, while the power pins may vary depending on the CAN device. The pinouts shown are for a SCADAS CN-4 card.
 

A minimum of two pins are used to connect the device to the Simcenter SCADAS:  

And other pins can be used as needed:

When using a digital sensor over CAN bus, sometimes devices are powered over the CAN cable on pins 1 and 5. CAN bus power options for various hardware: 

For various SCADAS hardware, CAN power schemes are as follows:

Cables are used between connectors on the CAN device and the Simcenter SCADAS. 

4.2 Cables 

A CAN bus cable is used to connect the output of the CAN device to a Simcenter SCADAS. 

Depending on the Simcenter SCADAS hardware, a variety of cable adaptors are provided to go between the CAN bus output of a device and into the SCADAS hardware (Figure 7): 
 

Some CAN devices (like a vehicle) might have the CAN bus output on an OBD (Onboard Diagnostics) connector.  In this case, an additional cable may be required to connect the OBD to a standard 9 pin CAN connector.   

An example OBD-II to CAN 9 pin cable is shown in Figure 8 below:  
 

Any one of the following OBD-II cables are recommended because they have the proper connections: 

It is important to use the correct OBD to CAN bus cable with a vehicle.  If other connections are made other than the three pins, problems can occur.  For example, a power connection made on one of the other pins can burn out vehicle electronics.   

4.3 Simcenter SCADAS CAN Cards and Status Lights 

Simcenter SCADAS hardware has specific cards for CAN communication.  Lights next to the CAN connections indicate the status of the connection. These lights become active after ARMING the Simcenter SCADAS hardware from Simcenter Testlab.

4.3.1 Simcenter SCADAS SYSCON Controller 

The main controller interface card (SYSCON) on a Simcenter SCADAS usually has a single CAN bus input as shown in Figure 9. 
 

There is an adaptor cable that is used with the SYSCON CAN connection. 

4.3.2 Simcenter SCADAS CN-4 Card 

The SCADAS CN-4 card (Product code: SCM-CN4) has two 9 pin serial connectors as shown in Figure 10. 
 

Each of the 9 pin connectors can accommodate two CAN connections.  A splitter cable is required (see previous sections). 

4.3.3 Simcenter SCADAS RS

The Simcenter SCADAS RS is ruggedized hardware which can be used outdoors in a variety of conditions.  It has no external lights (Figure 11) on the CAN bus interface to minimize entry point for water and dust intrusion.
 
The Simcenter SCADAS RS Recorder App or Simcenter Testlab Neo software can be used instead to indicate if there is CAN traffic on the port.

4.3.4 Simcenter SCADAS Lights 

In Figure 12 below, lights are shown for two different conditions on a Simcenter SCADAS: 
 

Figure 12: Red light (on CN-4 card) indicates a problem with CAN connection (improper termination, baud rate, etc).  Green light (on SYSCON card) indicates CAN is turned ON. 

When a CAN channel is turned ON, usually it will be either a solid green light or a solid blue light. When there is a problem, like an incorrect baud rate or improper termination, the light next to the CAN interface on the Simcenter SCADAS will turn red. 

5. CAN Bus Hardware Terminators 

Improper termination of a CAN bus is another possible reason that no signals may appear in a CAN bus network. In fact, correct termination of the CAN bus is critical for the correct functioning of the entire bus, as it impairs electromagnetic reflections between the two ends of the bus which jeopardizes communication. 

5.1 Terminator Overview 

The longest cable (or bus) length must be terminated by a 120-ohm resistor at both ends. The resistors are between the CAN high and CAN low wires at the location where they are placed on the network (reference for CAN high and CAN low see previous section). Termination is especially important when the CAN cable lengths are long. 
 

A Simcenter SCADAS measurement system does not have built in terminator on the CAN bus port, therefore external terminators must be added when required.  

In Figure 13, two different examples of 120 ohm terminators are shown. 

Figure 13: Left – 9 pin serial 120 ohm resistor, Right – Lemo style resistor for a digital sensor 

To apply termination to the Simcenter SCADAS end of the CAN bus, a terminator resistor such as the one depicted in Figure 13 (left side) can be used.  

Any Simcenter SCADAS module capable of CAN bus communication comes with a dedicated cable for the CAN port which ends with a serial 9 pin connector. A terminator (if needed) can be placed on the 9 pin connection as shown in Figure 14.

Figure 14: Example of applying a 120-ohm terminator on Simcenter SCADAS CAN bus cable. A Simcenter SCADAS does not have built-in termination and depending on the scenario, adding an additional terminator as shown may be required.

Note also that in some cases, e.g. when the CAN bus or cable used is relatively short, using only one terminator might be sufficient. However, termination on both ends will not harm in that case too, so best practice is to apply a terminator on both sides to avoid any issue. 

Let’s have a closer look at those cases and understand when termination is required and when it is not for some specific scenarios explained in the next sections. 

5.2 Vehicle CAN Bus Termination 

When connecting to a vehicle CAN bus instead (Figure 15), additional termination on the Simcenter SCADAS is usually not required.  
 

Figure 15: Simcenter SCADAS setup for reading a vehicle CAN bus.  No additional 120-ohm terminators are required since the vehicle CAN bus is already terminated. 

For a vehicle CAN bus to function properly, it already has terminators at the ends of the its internal CAN cable.   
 

It will not be necessary to provide additional CAN termination since the internal vehicle bus is already terminated. 

5.3 Digital Sensor CAN Bus Termination 

Figure 16 shows the setup of a digital sensor or a digital sensor module (for example a wheel force transducer, an inertial measurement unit, or a thermocouple digital sensor module) to a Simcenter SCADAS.  

Figure 16: Simcenter SCADAS setup and CAN cable setup for digital sensors.  Two terminators (blue, 120 ohm) must be placed near the ends of the CAN cable. 

The CAN bus must be terminated on both ends: at the Simcenter SCADAS and at the digital sensor. The Simcenter SCADAS has no internal termination. 

In many cases termination can be applied similarly on the digital sensor or digital sensor module end of the CAN bus, that is when a serial 9 pin connector is attached to such device. In other cases termination can be also built-in in such device – it may be relevant to check in the related device user manual.  
 

Note that the termination does not need to be at the very end of the connecting CAN bus cable.  However, the CAN bus cable length past the terminator must be short compared to the main length of the connecting cable. 

5.4 Digital Sensor Termination Example: Thermocouple 

A Simcenter SCADAS TCK8 thermocouple device is a digital sensor module. This means that proper termination must be applied, and to do so two terminators are used as shown in Figure 17: 

Figure 17: Connection of a Simcenter SCADAS TCK8 thermocouple device to Simcenter SCADAS has two terminators, one on the cable connecting to the SCADAS, the other near the digital sensor. 

More about measuring thermocouples with the TCK8 CAN bus thermocouple device, see the knowledge article: Simcenter Testlab Thermocouples.

6. Software: Configuration Files and CAN Parameters 

There are several settings in the Simcenter Testlab software interface that need to reflect the physical CAN configuration being used. These settings are set using a combination of configuration files (*.dbc or *.arxmll) and by settings in the Simcenter Testlab software interface. 

6.1 Configuration Files: DBC and ARXML 

When acquiring data over the CAN bus, either a DBC file (*.dbc) or a ARXML (*.arxml) configuration file is used to decode the signals.  

These files contain: 

• List of all Electronic Controls Units (ECUs) 
• List of all input and output Signals broadcast between ECUs 
• Scale factor, offset, and default values for each CAN signal 

Information in the file is specific to a particular vehicle model year and powertrain. 

DBC files are ASCII text files. They can be edited with tools like Notepad. An example of a DBC file’s content is shown in Figure 18. 
 

Figure 18: Contents of a DBC file showing the signals carried by two different Electronic Control Units (ECUs).

DBC or ARXML files are specific to a vehicle platform, model year, and powertrain.  The files do not contain generic information that works on all vehicles.  If the information in the configuration files (*.dbc, *.arxml) do not match the information being transmitted on the CAN network, no information can be decoded and displayed. 
 

When using Simcenter Testlab, a log file is generated that indicates inconsistencies between the broadcast data and the information in the configuration file.  

The inconsistencies log file, called “CAN_db_parse_log.txt” is in the directory C:/users/login/AppData/Local/Temp.  There are many files in this directory, but searching for the word “CAN” in windows explorer helps find it quickly as shown in Figure 19: 
 

 Figure 19: The “CAN_db_parse_log.txt” file contains information about message/channels that could not be read on the CAN bus. 

After opening the file in Notepad (or similar application), information about why specific messages on the CAN network could not be read are logged as shown in Figure 20: 
 

Figure 20: Contents of a “CAN_db_parse_log.txt” file can indicate why certain messages are not read. 
 

It might be that a vehicle is only available for a short time, and a proper configuration file (*.dbc or *.arxml) is not available in a timely manner.  In this case, the entire raw CAN bus data stream can be recorded for decoding at a later time.  

In the Channel Setup of Simcenter Testlab, make sure the “Save Raw Data” under the digital bus channels is turned on as shown in Figure 21: 
 

Figure 21: After activating the CAN bus, make sure the ”Save Raw Data” checkbox is ON. 

With the “Save Raw Data” turned on, the entire raw CAN bus data stream is recorded in parallel along with the decoded signals.  By default, the “Save Raw Data” option is turned on. 
 

 
More information on decoding raw CAN data after the measurement in this knowledge article: Record Raw CAN Bus Data and Decode Offline!

6.2 CAN FD versus CAN Bus 

CAN FD (Flexible Datarate) is an improvement of classical CAN.  CAN FD adds two main improvements: 

• Higher Date Transfer Rate: Data can be transferred at a higher rate – up to 8 Mbit/s compared to 1 Mbit/s. 
• Larger Message Size: A higher max payload size up to 64 bytes compared to 8 bytes in classical CAN.  This allows more signals to be carried in a single message. 

After its release in 2012, CAN FD is being more and more adopted by vehicle manufacturers and their suppliers to cope with the increasingly demanding bandwidth requirements of the automotive industry. However, many vehicle buses today still rely on standard CAN. Furthermore, when it comes to digital sensors for durability and NVH applications standard CAN based physical and data layers covers most of the cases. 
 

 
When setting up the vehicle CAN bus connection it is then important to know if it is a CAN or a CAN FD network. This parameter then needs to be properly selected in the Simcenter Testlab interface as shown in Figure 22. 
 

 Figure 22: Left - In Simcenter Testlab Neo, under "Conditioning" select "Digital CAN" for normal CAN bus and "Digital ISO CAN FD" for CAN FD. Right -In SImcenter Testlab "Classic", under “Controller Mode” select “Standard CAN” or “ISO CAN FD” based on the type of CAN network being used. 

If the SCADAS hardware only supports CAN, then the Controller mode selection is grayed out.  If it supports CAN FD, it can also support standard CAN, so both selections appear.

It can be difficult to physically distinguish a standard CAN network from a CAN FD network.  The physical connectors are the same. 

There are a couple of methods to determine if the network being read is standard CAN or CAN FD:

• General Knowledge: The vehicle network owner should know; hence the information should be available with a colleague or a supplier. 
• Configuration File: The database file used to decode the CAN signals (more about this in upcoming sections).  This file would have either a  *.dbc file or *arxml file extension. 

To determine if a CAN network is standard CAN or CAN FD from a configuration file, open the *.dbc file with a text editor.  Search for the parameter “BusType” which will be set to CAN ("BusType" "CAN") or CAN FD ("BusType" "CAN FD"). See example in Figure 23 where this parameter is set to CAN FD. 
 

Figure 23: After opening a *.dbc file with a text editor (Notepad on a PC for example), the parameter “BusType” indicates whether the bus is CAN FD or not. 

Note also that "BusType” is an optional parameter to be specified in a DBC file so it is not always available. 
 

 
In the case there is an.arxml file related to the vehicle network it can be loaded in the Simcenter Testlab interface CAN based setup as shown in Figure 24:
 

Figure 24: Loading Autosar (*.arxml) file.

Termination is more critical for CAN FD due to the higher data rate, hence even for a short bus it is important to place two terminators as close as possible to the end of the CAN network.  See previous sections on termination. 

6.3 Baud Rate 

CAN bus devices operate at a specific baud rate. The baud rate must be set in the Simcenter Testlab interface (Figure 25) and must match the baud rate of the CAN hardware (vehicle network or digital sensor). 
 

Figure 25: Baud rate of 500000 is common for CAN devices. 

Many CAN bus networks work at a 500,000 baud rate.  When in doubt, this is a good number to try.

This information should be known by the network owner or the digital sensor provider but can optionally also be found in the related .dbc file or .arxml file. See again Figure 23 above where this parameter can be found as “Baudrate”, when opening the .dbc file in a text editor. 
 

If this parameter is specified in the .dbc file (or in the .arxml file) this will be picked up automatically by Simcenter Testlab and will be greyed out in the interface without further user action required. 

6.4 CAN Sample Point 

This is the point at which the logical value (0 - dominant or 1 - recessive) is defined (or sampled) along the bit duration and is expressed in percentage (%). For standard CAN a value of 75 % works in most of the cases and is used by default by Simcenter Testlab, hence does not require any additional user interaction in this case. 

6.5 CAN FD: Data Rate and Data Sample Point 
 
Due to the additional flexibility on the CAN FD networks, there are two additional parameters that need to be defined specifically for CAN FD networks: 

• Data Rate: Rate at which the data or payload is transferred. In practice usual values are 1 and 2 Mbit/s (1000000, 2000000, 5000000, etc.)
• Data Sample Point: This is the point at which the logical value (0 - dominant or 1 - recessive) is defined (or sampled) along the bit duration for the payload part of the message and is expressed in percentage (%)

Note: Do not confuse CAN Baud Rate and CAN FD Data Rate.  These are two independent parameters, and CAN FD Data Rate is unique to CAN FD as shown in Figure 26.

Figure 26: For a CAN FD network, both the "Baud rate" and "CAN data rate" need to be set (shown in Simcenter Testlab Neo interface).

For these parameters to be used, the Controller Mode must be selected as ISO CAN FD. 
 

The Data Rate is optionally available on the .dbc files and when available is also automatically picked up by the Simcenter Testlab interface, while the Data Sample Point is rarely available on such file. 

Both parameters are more often available when using an .arxml file.  They will be automatically picked up by the Simcenter Testlab interface (after the CAN FD conditioning mode is selected). 

6.6 CAN Acknowledge: Active versus Passive  

Switching the "CAN Acknowledge" setting from Active to Passive (or vice versa) will often solve CAN communication issues.  

This setting is found in the CAN setup as shown in Figure 27: 

Figure 27: CAN Acknowledge selection of Active and Passive 
 

CAN bus signals require “acknowledgement”.  If there is no receiver that acknowledges the signals, the CAN signals will cease to be broadcast.  Acknowledgement means that the broadcasting device receives information back indicating that the CAN signal is being properly received. 

Active versus Passive settings: 

• Passive: The CAN signals of interest are already being acknowledged by another device besides the Simcenter SCADAS. Setting the Simcenter SCADAS to “Passive” avoids redundant messages on the bus. In most vehicle buses, an acknowledging device is already present. 
• Active: By setting to Active, the Simcenter SCADAS will acknowledge the messages. It is important when no other device on the CAN network is performing acknowledgement.   

 

Three different scenarios for selecting Active versus Passive: 

• For reading CAN bus signals from a typical vehicle bus, passive mode suffices because the vehicle is acknowledging.  More information: CAN Bus Measurements.
• Legislated signals for emissions which can be read over Onboard Diagnostic connector need to be acknowledged (Active mode): No more tach! Use OBDII to get Engine and Vehicle Speed...
• Digital sensors require acknowledgement (Active mode): Simcenter Testlab Thermocouples

7. Decoding Tips 

Decoding relates to the process of converting CAN messages (which only contain digital information) into engineering signals which can be displayed and interpreted in a traditional measurement along with simultaneously acquired analog data as shown in Figure 28. 
 

Figure 28:Raw CAN binary data (left) is decoded and turned into engineering signals (right).

 

Bear in mind, however, that before taking steps into verifying the decoding it is necessary to assess that the basic CAN bus communication and traffic is properly established when troubleshooting an malfunctioning CAN configuration.  

How to assess this is explained in the following subsections. That is also a good starting point to look at more decoding tips, which are then given further below in the article. 

7.1 RDDF File 

A good way to validate that basic physical connections are done properly or that basic CAN configuration parameters have been properly chosen etc. is to visualize and analyze the content of the raw CAN data acquired during a Simcenter SCADAS recording. 

After making a recording with the ‘Record Raw CAN bus’ option switched ON, an “*.rddf” file is automatically recorded together with the rest of the data. This is indicated within Simcenter Testlab with the dedicated Digital Bus Data icon (see Figure 29) and the related files can be found in related run directory. 
 

Figure 29: Digital Bus Data indicates the entire raw communication on the CAN bus was recorded (orange highlight) and available in the Simcenter Testlab project

The *.rddf file contains all the CAN bus signals which are available on the bus in a raw format (i.e. before any decoding is applied). 

7.2 Reading a RDDF (Raw CAN) File

The *.rddf file stores binary data for compactness reasons but can be converted to ASCII format to be read and interpreted. This can be accomplished in two different ways. 

7.2.1 RDDF to ASCII Standalone Converter

First, through the special “RDDF to ASCII Converter” tool found in the “Tools” menu of the Simcenter Testlab folder (Figure 30): 
 

Figure 30: The ‘RDDF TO ASCII’ tool.

 

After selecting the RDDF file, the "Convert to ASCII" button will make a ASCII version of the file that can be read with Windows Notepad.  The ASCII file ends with a *.asc extension.  

The ascii (*.asc) version of the *.rddf has a certain structure as shown in Figure 31: 
 

Figure 31: Once the *.rddf file is converted to ascii format, this can be visualized in a text editor and interpreted. This contains all the messages passing on the bus while recording in terms e.g. of their CAN identifier (CAN ID) and their content (Payload \ Data). 

The converted file contains all the messages passing on the bus sorted by time stamp. The most important information is the CAN identifier of the message (CAN ID) which is a unique number identifying the message, and the payload which contains the actual data being transmitted. 

7.2.2 RDDF to ASCII in Simcenter Testlab Neo

A second method to visualize the content of the *.rddf file is through the Simcenter Testlab Desktop Neo application. This can be done through the dedicated context menu action shown in Figure 32.
 

Figure 32: The *.rddf file can be also converted to ascii and visualized directly from within Simcenter Testlab Neo by right clicking on the digital data icon and selecting "View".

Right click on the Digital Data Bus in the Navigation tree and choose "View".  The ASCII file is then shown directly on the screen.

7.3 Validate CAN Traffic Via RDDF ASCII File 

The RDDF ASCII file will either be "empty" (ie, no CAN traffic recorded) or populated with CAN messages.

7.3.1 Empty RDDF ASCII File

When reading the ASCII CAN file, it could be a "empty" file.  It would be small in size (4 to 5 kilobytes) and not contain meaningful messages. Examples of empty files are shown in Figure 33.
 

Figure 33: Example empty RDDF files: Left - SCADAS Mobile/Recorder file is empty.  Right - SCADAS RS empty file consists of strings of FFFFFFFF.

Empty files can point to some different issues:

• CAN bus Off: First, it might simply mean that the bus or device is switched off or not ready to send the required data for some reason. 
• CAN Connections: Possible problems can include missing termination, incorrect connections, or no CAN data on selected CAN location.
• CAN Settings: a wrong baud rate, or similar issues that have been covered in the previous sections of the article.
• Message Requests: Alternatively, if we are sure that the device is ready turned on and ready, then the issue might be related to some higher layer protocol action required to get the necessary data on the bus before they can be picked up – see one of the following sections on Message Requests in this case.

7.3.2 Populated RDDF ASCII File

Figure 34 summarizes some characteristics of the *.rddf file containing the raw CAN data of a particular CAN bus in function of different situations, starting from a “good” one where all parameters are set correctly.

Figure 34: By looking at the raw CAN data contained in the *.rddf file, it can be verified that the CAN bus traffic is being properly recorded 

If CAN messages were recorded,  the file will have a non-negligible size (more than a few kilobytes for a 4-5 sec acquisition time).  In the file and when looking at its content we can clearly distinguish different CAN messages with multiple different CAN identifiers, and meaningful and varying payloads. This indicates that traffic can be properly recorded and if the required signal is not yet visible in Simcenter Testlab, then the issue is most likely related to decoding or alternatively some dedicated higher layer issue (see following sections). 

 7.4 Checking Messages in RDDF ASCII File versus DBC/ARXML 

After the RDDF is converted to ASCII and it is verified that this contains meaningful data (as explained in earlier subsections) then more troubleshooting can be performed.  

For example, it is possible to verify the messages that are present on the bus are the same ones that are available on the dbc file. The dbc file indeed contains the information which is necessary to decode the messages available on the bus. If no match can be found between the CAN identifiers on the dbc and on the raw CAN data recorded on the *.rddf file, then no decoding will happen, and no engineering signal will be created and visualized inside the Simcenter Testlab application. 

An example is shown in Figure 35 where a specific message (“LeftFront_3”) with CAN identifier 780 in decimal (corresponding to 30C in hexadecimal) is available and properly recorded in the *.rddf ASCII file. This means that a Testlab channel will be created whenever signals related to this message are activated within the software interface. 

Figure 35: By comparing the CAN identifiers listed in the DBC file with the ones available on the RDDF file it is possible to verify if the proper decoding information is available on the DBC file and reversely if the expected data is available on the CAN bus as part of the traffic. 

Note that message ids are stored in decimal format in DBC files, while in hexadecimal in the RDDF. So a conversion between the two formats needs to be done to properly assess if any matching is present. There are many hexadecimal to decimal converters online, and also the Windows Calculator offer this functionality. 

If a there is no match for the DBC entries corresponding to the signals, the following are possible:: 

• The DBC file is incorrect, i.e. for example some of the CAN identifiers are not correctly specified there. This might be because of an outdated dbc file.  A manual change aimed at matching the RDDF entry could solve the situation. 
• Data not on CAN bus: The message data may not be on the CAN bus. One cause could be not connecting to the proper vehicle CAN bus, It might be necessary to switch to a different connection point on the vehicle to look for the required messages and data. Could also be because the necessary data has to be requested before it will be available on the data as in the case of OBD-II or J1939 PGN request. See more on this topic further down in the article. 
• Specific Source Addresses: Another potential reason there is no match between DBC file entries and any of the messages recorded on the RDDF file might be related to the use of a specific Source Address used by the device which is sending the data.  This can be the case when the device is using the SAE J1939 protocol. This is a higher layer protocol running on 29 bit CAN for which some extra definitions are applied and used. 

For more information, see the knowledge article: Record Raw CAN Bus Data and Decode Offline!

7.5 Message Request: OBD-II and  SAE J1939 

If traffic has been properly verified and assessed according to the previous sub-sections of the article, i.e. it has been verified that raw CAN data is properly recorded in the *.rddf file, but we are not able to find the expected messages on such traffic, then it might be that the required data must be requested before it becomes available. 
 
Specific higher layer protocols indeed define the rules for such options where specific message requests are sent to a device which will then respond with the required data. A common is the OBD-II protocol which is a diagnostic protocol widely used in automotive, where specific parameters can be requested (e.g. vehicle speed and engine rpm) addressing all devices on the network or specific ones through their specific addresses,

Another protocol which uses message requests is the SAE J1939 protocol which is widely used in the off-highway industry where specific PGNs (parameter group numbers) can be requested through a PGN request message which is broadcasted or directed to specific nodes on the network. Such request can be defined within Simcenter Testlab Neo Time Data Acquisition or Simcenter Testlab Neo Recording Workbook for Simcenter SCADAS RS.  There is a dedicated menu action on the specific data which needs to be requested (see Figure 36). 
 

Figure 36: J1939 PGN requests can be defined within Simcenter Testlab Time Data Acquisition and Simcenter Testlab Recording Workbook.  
 

Hope this CAN bus tip guide is helpful!  Questions?  Email scott.beebe@siemens.com. 

Related Simcenter Testlab Acquisition Tips

• Index of Simcenter Testing Knowledge Articles
• Simcenter Testlab Signature
• Hands-free acquisition (almost)
• Capturing Transient Events in Simcenter Testlab
• Cool Channel Setup tricks for Triaxial Accelerometers
• GPS triggered data acquisition
• How to calculate a VECTOR SUM
• Tips and tricks for acquiring torsional orders
• CAN Bus Measurements
• No more tach! OBDII for engine speed
• Record Raw CANBUS Data and Decode Offline!
• Single Plane Balancing in Simcenter Testlab
• Measuring strain gauges in Simcenter Testlab
• Correcting a bad calibration factor
• Simcenter Testlab Calibration