SaberRD Design Example: Vehicle CAN Bus Analysis

Datsen Davies Tharakan

Introduction:
In this example, the physical layer implementation of a CAN in-vehicle communication network is analyzed. The design consists of 14 Engine Control Units (ECU). CAN is a multi-master network, meaning that any network node can act as master or slave. Arbitration will take place at the beginning of a message frame if 2 or more nodes are attempting to transmit data. The winner of the arbitration acts as master and all remaining nodes act as slaves and listen to the bus for the remainder of the frame. For this example, 2 of the nodes will be designated as transmitters and will have to arbitrate for control of the bus. 

This tutorial will demonstrate the tools available to analyze the signal integrity and bit timing using the CAN Protocol Controller model. It will further demonstrate how the bit timing register (BTR) settings can be tuned to ensure proper bit timing under a worst case scenario. The following analyses will be performed: 

Nominal Case Analysis: 

• Typical BTR settings 
• Nominal oscillator frequencies 
• Questions answered: Does the design perform within specification under nominal conditions? 

• Worst Case Analysis: 
  • Typical BTR settings 
  • Worst case variation of oscillator frequencies 
  • Questions answered: Will the design remain within specification under worst case conditions? 

• Worst case analysis with variation: 
  • Variation BTR settings 
  • Worst case variation of oscillator frequencies 
  • Questions Answered: Can BTR settings bring the design into specification under worst case conditions? 

How to use the example:

1. Download the attached design (vehicle_body_can.zip) and unzip to a local folder.
2. Open the design, vehicle_body_can.ai_dsn in SaberRD.
   • Note: This design example works only in SaberRD commercial edition 2013.12 and above.
3. Nominal Case:
   1. In the Simulate tab, select Experiment and can_vehicle_body_nominal in the respective drop-down lists. 
      
   2. Click  to run the simulation. This verifies the Nominal Case.
   3. Graph1 shows up in the Results Pane. Double-click to view the graph.
4. Worst Case Design Analysis:
   1. In the Simulate tab, select Experiment and can_vehicle_body_wc in the respective drop-down lists.
   2. Click  to run the simulation. This verifies the Worst Case simulation with failure in data transfer.
   3. Verify can_report.txt, which is created in the same folder as the main design. See that  bits 10, 12, and 13 of ECU5 have bit timing errors.
   4. Graph1 shows up in the Results Pane. Double-click to view the graph.
5. Worst Case Analysis with parameter variation:
   1. In the Simulate tab, select Experiment and can_vehicle_body_wc_adj in the respective drop-down lists.
   2. Click  to run the simulation. This verifies the Worst Case Analysis with the adjusted parameters.
   3. Verify can_report.txt, which is created in the same folder as the main design. See that all bits are OK.
   4. Graph1 shows up in the Results Pane. Double-click to view the graph.

Circuit Snapshot: