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:
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:
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:
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:
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 26:
Figure 26: 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:
Three different scenarios for selecting Active versus Passive:
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 27.
Figure 27: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 28) and the related files can be found in related run directory.
Figure 28: 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 29):
Figure 29: 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 30:
Figure 30: 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 31.
Figure 31: 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 32.
Figure 32: 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:
Figure 33 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 33: 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 34 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 34: 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::
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 ah a dedicated menu action on the specific data which needs to be requested (see Figure 35).
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 email@example.com.
Related Simcenter Testlab Acquisition Tips