Dealing with the CAN Bus, Part Three
IN THE LAST article, we explained the content of the CAN frame and showed how to visualise it on a PC based analysis tool via the OBD connector, which is in cars manufactured in the past ten years or so. The CAN frame consists of the Identifier (ID), Control (Data Length), Data (up to 8 Bytes) and error checking (CRC) portion. As shown in Figure 1, this can be displayed in an analyser where you can see this information on the CAN bus. Now the question is – what is this telling us? Here you can see the CAN IDs, their Data Length (DLC) and the raw data in Hexidecimal format, along with the timestamp for each message. Also seen here is the Frame Rate, which is interpreted into Bus Load. Here we see a Bus Load of 11.9 % (max 15.82%), which is quite a low Bus Load compared to higher spec vehicles today.
Here, we’ll explore how we can interpret this information utilising what is known as the CAN database – also known as the CANdb. If you need a review, read the two prior articles first. [See ‘more documents’ in the ‘recent articles’ section of aftermarketonline.net – Ed]
Can frame
The CANdb file gives a breakdown of the CAN frame information - what the CAN frame Identifier represents and how the data in the CAN frame is interpreted to give engineering values such as engine speed, road speed, etc. Once the CAN frame is passed from the CAN interface to the microcontroller of the ECU, the CANdb sets the rules on how the data is stored in the controller’s register, how each signal is extracted from the register and how the data is scaled to give the engineering values.
This vehicle had few ECUs as it was a five-year old basic small coupe. Looking at the CANdb editor in Figure 2, it can be seen there are ten CAN messages designated. The messages include info from the Engine Control, Transmission Control, ABS, Powertrain and Instrument Pack modules. Note the Message/Signals tree on the right side of the display.
As an example, here we have the Engine 1 Message highlighted. In the main window, all the Signals within this message are outlined. The CAN ID is 201 Hex and this message has 8 Bytes of data. The ID Format is Standard, which means the ID is 11 bits – Extended Format allows for a 29 bit ID. Also note that the bit representation of all the signals is shown at the bottom of the display, where you can see how the 8 Bytes of data are distributed.
Backwards and forwards
In this example, the Engine_Speed_RPM signal is outlined. Figure 3 shows the details of the Engine_Speed_RPM signal. This shows how the data is extracted from the CAN message and how it is processed by the ECU software. You can see that the Engine_Speed_RPM signal within the Engine1 CAN frame (ID 201 Hex) is allocated 16 bits and it is extracted from the start bit of 7. The Bit Format is Motorola Backwards.
In the CAN specification, there are three standard ways of allocating signals within a CAN frame – Intel, Motorola Backwards and Motorola Forwards. Most vehicles today use either Intel or Motorola Backwards. These formats set the boundaries and positions of the data. Referring back to Figure 2, it can be seen in the Data Visualisation Component at the bottom where the Engine_Speed_RPM signal is placed in the data area of the CAN frame.
In Figure 3, you can see that the Engine_Speed_RPM signal is given a Multiplier of 0.25 and an Offset of 0. Sometimes there is a negative offset for a signal such as temperature. The minimum of 0 and maximum of 16,383.5 RPM is set. This is the result of dividing the raw values of the 16 bit signal by ¼. The maximum raw value of 16 bit parameter would be 65,534 before it is reduced by ¼.
Model ECU
Once the data is allocated to an ECU, it is then processed according to the specifications of this particular vehicle model. Going back to our CAN analyser, we can load a CANdb into the analyser to interpret that CAN ID and raw data seen in Figure 1.
In Figure 4, it can be seen that once a CANdb file is loaded, the CAN IDs can be displayed by their allocated message name e.g. Engine1, Powertrain2, ABS1, etc. The display still shows the raw data, so the next step is to go to a Signals display to show how the raw data is processed to give engineering values.
Figure 5 is the Signals display of the analyser that shows the engineering values of the CAN data after it has been processed via the CANdb. Here we show several Signals highlighted in colour. These are mapped into the scope display as shown in Figure 6. Before we go to Figure 6, we’ll discuss the Signals display. Here it can be seen the instantaneous values of each of the Signals designated in the CANdb file loaded. We use the Signal Comment to indicate the CAN message each Signal came from. This information can be logged to a CSV file for later viewing of the whole session in a spreadsheet.
Scope it out
Figure 6 shows the CAN analyser’s Scope display showing the trend of selected signals over a period of time. As mentioned earlier, these signals are mapped in from the Signals display as shown in Figure 5 with the assigned colours. The signals are updated in a scope format to show the trend of each of the selected signals during the data collection session. For example, the relationship between the throttle position (pink line) and engine (purple is illustrated here, as well as the road speed (green) and engine coolant temp (red). Many analysers provide other means of displaying signals, such as dial displays, bar codes, etc.
As discussed here, the CAN database (CANdb) is a file that is generated based on the specification of your particular vehicle. The CAN db will tell you what information is in each CAN ID. It also establishes how the raw digital data is extracted from the CAN frame and scaled before it is passed onto the microcontroller in the ECU for processing.
CAN opener
Most car companies have their own methods of interpreting CAN data, i.e. specifying the CANdb. Unfortunately, these car companies treat this propriety information as confidential and they are not readily willing to share this information with the Aftermarket. There have been methods for ascertaining the CAN data information for developing CAN databases from past knowledge and reverse engineering. This is a difficult area that requires either a good relationship with the OEM or some clever reverse engineering methods to obtain relevant Signals information. For those in low quantity production vehicle industries (truck, bus, construction, agricultural, etc.), life is a bit easier. There are standards utilised in these industries that designate standard CAN message IDs and the format of the signals data in the messages. The two popular CAN higher layer standards are CANopen and SAE J1939.
