Controller Area Network (CAN)

Bosch developed the Controller Area Network (CAN) in the mid-1980s. Using CAN, devices (controllers, sensors, and actuators) are connected on a common serial bus. This network of devices can be thought of as a scaled-down, real-time, low-cost version of the networks used to connect personal computers. Any device on a CAN network can communicate with any other device using a common pair of wires.

As CAN implementations increased in the automotive industry, CAN was standardized internationally as ISO 11898. CAN chips were created by major semiconductor manufacturers such as Intel, Motorola, and Philips. With these developments, manufacturers of industrial automation equipment began to consider CAN for use in industrial applications. Comparison of the requirements for automotive and industrial device networks showed numerous similarities, including the transition away from dedicated signal lines, low cost, resistance to harsh environments, and high real-time capabilities.

CAN Calibration Protocol (CCP)

The amount of electronics introduced into the automobile has increased significantly. This trend is expected to continue as automobile manufacturers initiate further advances in safety, reliability and comfort. The introduction of advanced control systems—combining multiple sensors, actuators and electronic control units—has begun to place extensive demands on the existing Controller Area Network (CAN) communication bus. To enable the new generation of automotive electronics, new and highly sophisticated software, calibration, measurement, and diagnostic equipment must be used. At this time almost no standards exist in the area of software interfaces for such devices. Each company has its proprietary systems and interfaces to support the development of these high-end configurations.

The CAN Calibration Protocol was originally developed and introduced by Ingenieurbüro Helmut Kleinknecht, a manufacturer of calibration systems, and is used in various application areas in the automotive industry. Afterwards CCP was taken over by the ASAP working group and enhanced with optional functions and is now maintained by the ASAM organization.

Scope of CCP

The CAN Calibration Protocol is a CAN-based master-slave protocol for calibration and data acquisition using the CAN 2.0B standard (11-bit and 29-bit identifiers), which includes 2.0A (11-bit identifier). A single master device (host) can be connected to one or more slave devices. Before a slave device may accept commands from the host, the host must establish a logical point-to-point connection to the slave device. After this connection has been established, the slave device has to acknowledge each command received from the host within a specific time.

CCP offers continuous or event driven data acquisition from the controllers, as well as memory transfers to and control functions in the controllers for calibration purposes.

With these functions, CCP may be used in:

  • The development of electronic control units (ECU)
  • Systems for functional and environmental tests of an ECU
  • Test systems and test stands for controlled devices (combustion engines, gearboxes, suspension systems, climate-control systems, body systems, anti-locking systems)
  • On-board test and Measurement systems of pre-series vehicles
  • Any non-automotive application of CAN-based distributed electronic control systems

CCP defines two function sets—one for control/memory transfer, and one for data acquisitions that are independent of each other and may run asynchronously. The control commands are used to carry out functions in the slave device, and may use the slave to perform tasks on other devices. The data acquisition commands are used for continuous data acquisition from a slave device. The devices continuously transmit internal data according to a list that has been configured by the host. Data acquisition is initiated by the host, then executed by the slave device, and may be based on a fixed sampling rate or be event-driven.

CCP Protocol Definition

Two communication objects are defined by CCP to handle the communication between host and slave devices—The Command Receive Object (CRO), which is used to send commands and data from the host to the slave device; and the Data Transmission Object (DTO), which is used to transmit handshake messages, data, and status information from the slave device to the host. Each of these message objects is assigned a unique CAN ID. Messages that are returned from the slave as a message to a command are called Command Return Messages (CRMs).

A Command Receive Object is a CAN message consisting of eight bytes. The first byte of a CRO is the command code, followed by the command counter byte. The command counter is generated for reference by the host to make sure that the CRM returned by a slave device corresponds to the correct host command. The rest of the message builds the parameter and data fields. The structure is as follows:

A Data Transmission Object has a Packet ID (PID) as the first byte. This PID determines how the rest of the message is interpreted. CCP differentiates between three types of DTOs:

PID Type
0x00–0xFD Data Acquisition Message
0xFE Event Message
0xFF Command Return Message

Event Messages and Command Return Messages have the following structure:

In the case of an Event Message, the Counter field does not contain valid data and has to be ignored by the host. For Command Return Messages (CRMs), the Counter field must have the same value as the counter field of the corresponding CRO. The error field contains information about the error state. The parameter and data fields contain the data returned from the slave device to the host. Event Messages and CRMs consist of eight bytes.

Data Acquisition Messages (DAQ Messages or DAMs) have a PID in the first byte, and the rest of the message contains data. DAMs may be shorter than eight bytes:

Since the PIDs 0x00–0xFD are reserved for Data Acquisition Messages, a CCP slave device can send up to 253 different DAMs. Each DAQ message can transfer up to seven bytes of data. The number of DAQ Messages supported by a slave device depends on the device itself.

Data acquisition is performed through a CCP slave device by reading data from a device's memory and copying it into the data field of a DAQ message. So the CCP slave device keeps a list of entries for each DAM. These lists are called Object Definition Tables (ODTs). Each ODT entry holds information about the memory address where data is stored inside the device and the size of the data to be sent. The data of the first ODT entry is placed in the first byte of the data field of the DAQ message. The data of the next entry is placed at the first free byte of the DAQ message, and so on.