Kvaser reached out to me about writing a sponsored post to put on this site. I have used many Kvaser CAN interfaces in the past. Since they work well and are reliable I agreed. I also dont know anything about CCP/XCP; so this should be interesting.

This is my first time accepting a sponsored post (and is the only post on this site that I did not write). If you like or do not like this let me know in the comments below.

The Control Area Network (CAN) is an incredibly robust system. It is because of this that the protocol is can be used for data collection and calibration across a variety of industries. CAN contains five different error checks throughout the communication protocol to ensure data are transmitted correctly. If an error is detected, CAN will retransmit the data until they are received without error. Partially because of the robustness of the system, CAN has become the standard within the automotive industry and a compelling choice for autonomous systems in robotics.

Error Detection With CAN

One of the greatest advantages of using CAN for device communication is the protocol’s stellar acuity at error detection. During transmission, messages are tested for errors by each CAN controller connected to the common bus line. Each message in a CAN bus is given a priority, with error messages ranking as the highest priority. If an error condition occurs, the CAN frame is interrupted to force retransmission as soon as possible.

The CAN protocol has five methods of detecting errors, including:

• Bit Monitoring: Each transmitter monitors signal levels, signaling a Bit Error if the actual bit level reads differently than the one transmitted. This ensures that all global errors are detected.
• Bit Stuffing: A 6th bit of the opposite level is added to the outgoing bit stream after 5 consecutive bits of the same level have been transmitted (it is then removed by the receivers). If more than 5 bits of the same level are transmitted, a Stuff Error will occur.
• Frame Check: Parts of a message will have a fixed format. If the controller identifies an invalid value in one of these standardized fields, an Error Form will signal.
• Acknowledgement Check: Each node on the bus will send a dominant level to the acknowledge (ACK) slot when a message is received. If this is undetected by a transmitter, an Acknowledgement Error will occur.
• Cyclic Redundancy Check: Each message has a 15-bit cyclic redundancy check (CRC). If this is not detected by a node, a CRC Error will be signaled. This is the primary way local errors found among different receivers are detected. In other words, all CAN frames are broadcast in the CAN protocol, and the receivers of the information are selected by the software reading the received CAN frame from the CAN controller. This also ensures that all devices have exactly the same information available at exactly the same time so that processing is done with all the same information, allowing for a consistent control system.

CCP/XCP for Calibration

CCP (CAN Calibration Protocol) is the protocol used primarily within the automotive industry for the calibration of electronic control units (ECUs). CCP/CXP is a basic specification that makes it possible to read and write to the internal memories of an ECU. However, this protocol can be used in other industries, like robotics, for microcontroller development and similar functions. CCP is used to support the following functions:

• Read and write to ECU memory
• Cyclical data acquisition and concurrent calibration from an ECU
• Handling of multiple nodes on the CAN bus

The most recent version of CCP is the XCP standard, which improves upon several areas of calibration, including:

• Ease of Use: The XCP protocol has a more clearly defined standard, leaving less up to user interpretation and needing fewer proprietary variations.
• Improved Efficiency: More download and programming commands are available, which improves data transfers between devices and the ECU. XCP also features auto detection of slaves, a benefit exclusive to this calibration protocol.

Basic CCP/XCP Commands and Error Handling

Before commands can be sent, a logical connection between master/slave must be established. This connection will continue until a disconnect command or new slave node appears. The master controls all communication between the two. Because commands used in CCP/XCP are generic and not node-specific, each node has a unique station address. Every reply from slave to master will contain either data or an error code.

In order to establish a connection with an ECU it is always necessary to use the commands CONNECT at start and DISCONNECT to stop the communication link. For configuration of the CCP/XCP link there is a command EXCHANGE_ID to setup the session.

Common commands for CCP/CXP.[SOURCE]

CCP/XCP has changed over time so in many cases it is necessary for the tool to handle different versions of the CCP/XCP communication. To make this possible there is a command GET_CCP_VERSION to get knowledge how to use CCP/XCP with this particular ECU.

In some cases it is necessary to have some protection and in that case there is keying where commands GET_SEED, UNLOCK are used.

After the configuration all exchange is a write and read of the memory. There are two different means to do that, one for larger memory sections where SET_MTA define the memory address (virtual or real) and the reading and writing is done by UPLOAD and DNLOAD. This function is used when programming the ECU or to read and write larger sections of the memory.

To write parameters there is a second solution using the commands SET_DAQ_PTR and WRITE_DAQ. For the administration of this there are two commands GET_DAQ_SIZE and START_STOP. By this function it is possible to read or write a number of parameters in a data structure that fits into a data-package (8 byte in CAN). This function is used to set and get parameters without any knowledge about the actual location in a memory map. This is used to read back some internal parameters and adjust controllable parameters to calibrate the ECU to the best behavior.

CCP/XCP is not a complete standard for calibrating an ECU, but it is essential for making it possible to exchange information with an ECU. Which information to exchange and how that information is used in the ECU, is not defined in the CCP/XCP specification.

The CAN Protocol in Action

In 2008, Nexi, an MDS (Mobile, Dexterous, Social) robot, was named by Time magazine as one of the 50 best inventions for that year. This robot was considered revolutionary because of its ability to use verbal and non-verbal communication. CAN was chosen as the communications protocol for Nexi partly because of the system’s quick and reliable error detection methods. A dual channel CAN card was used for position feedback for motor control, and CANLib software was integrated into the existing API to interface with the CAN bus. In addition to humanoid robots of the future, CAN is also expected to continue as the staple for the auto industry—including use in autonomous vehicles.

PolySync (formerly Harbrick) has created a vehicle kit that will allow developers to design an autonomous vehicle. The revolutionary operating system simplifies the backend infrastructure, giving developers the freedom to focus on the code necessary for their unique vehicle. In this system, CAN continues as the chosen communications protocol because of the system’s proven reliability. Co-Founder and CEO Josh Hartung, explains “CAN’s real-time behavior, high message integrity and simplicity, among its many attributes, assures its place within the communication infrastructure of tomorrow’s vehicles, particularly for device/motion control, timing and data critical applications.”

CAN has long been the chosen protocol within the automotive industry, and, as autonomous vehicles emerge, it looks as though this will continue to be true. Because adoption of autonomous vehicles relies heavily on the guaranteed safety of users, the reliability of CAN makes the protocol an obvious choice.

To learn more about the CAN protocol, including error detection and calibration, visit Kvaser’s education portal here.

Click this link for a thesis on the Evaluation of Protocols for Transfer of Automotive Data from an Electronic Control Unit (provided from Kvaser).

About the author:
Jesse Paliotto is the Marketing Director for Kvaser AB. He holds an MBA in Business Strategy and Marketing and is based out of Kvaser’s US headquarters in Mission Viejo, CA.

Liked it? Take a second to support David Kohanbash on Patreon!