Calibration is a process of optimizing or tuning a control algorithm to get the desired response from the system. A calibration tool is a combination of a hardware interface and a software application that enables the engineer to access the calibration variables in an ECU and change them. Typical control algorithm components that need calibration are look-up tables, gains, and constants.
A powertrain control algorithm may have hundreds of calibrate-able parameters. The more parameters that are used, the more difficult the task of finding an optimal calibration. The calibration tool helps the engineer arrive at an acceptable calibration parameter set. All of the calibrate-able parameters are grouped into a special section of ECU memory called the calibration memory. Calibration tools give the user access to this memory to allow.
A basic calibration system consists of an ECU interface, a link to the host PC, and a PC application. A more capable system will add a vehicle network link as well as analog data acquisition modules. The ECU interface is typically a CAN interface when a CAN-based calibration method is used, or a Read-Only-Memory (ROM) emulator when a direct memory access method is used. The link back to the host PC can be CAN, USB, Ethernet, or other method. The PC application is typically a MS-Windows® application. Figure 1 shows a typical calibration system.
What is CCP?
The CCP (CAN Calibration Protocol) is, just as the name indicates, a protocol for calibration of and data acquisition from electronic control units (ECU). The protocol is defined by ASAM (Association for standardisation of Automation and Measuring Systems), earlier known as ASAP (Arbeitskreis zur Standardisierung von Applikationssystemen). This is an international organization consisting of a number of significant vehicle manufacturers i.e. Audi, BMW, VW etc. Until now different technical solutions have been used for developing, calibration, production and service of ECU hardware and software. The aim with CCP is to create a common tool for all stages of ECU developing and which is compatible with different kinds of hardware and software.
The ASAM group defines a lot of standards. The CCP and XCP standards are found in subsection AE (Automotive Electronics) and are grouped into something called AE MCD 1. The current version of the CCP specification is 2.1, released in February, 1999.
The CAN Calibration Protocol is basically used as a monitor program. Similar to many earlier serial RS232-type monitors and bootstrap loaders that provide basic read and write memory capabilities, CCP provides the same functionality using a standard protocol rather than a company-specific proprietary protocol. However, when a high-speed CAN bus is used, CCP, unlike some previous 9600 baud UART-based monitors, provides the ability to access data at such a fast rate that it is possible to run an application at the same time.
Developers now have a significant advantage over the earlier monitoring methods.
In the dialog used by CCP and most monitor programs it is the tool or PC that is the Master that sends commands into the ECU. The ECU does not send information without the Master (Tool) initiating commands. A CCP-compliant tool can read data from the ECU and can write data into the ECU with the appropriate CCP messages.
With CCP, the software developer can read:
With CCP, the software developer can write to:
However, this is only CAN Calibration Protocol’s minimum capability. CCP includes several additional monitor commands, and provides several new features including automatic data acquisition processing based on events or periodic updating, flash programming and data security. Since there is no requirement to use all its features, CCP is a scalable protocol.
CCP users have access to online measurement data and can calibrate modules, so software development can occur not only in a lab environment but also during an in-vehicle test.
What are the functions of CCP?
CCP is a application layer for CAN 2.0B (11- or 29-bits CAN id). The Protocol is a top layer (layer 7) according to the OSI model, which means that the protocol does not describe how bits and bytes are created but uses the CAN 2.0B protocol physical, data link and network layer.
CCP supports the following functions:
CCP in detail
CCP is built on a master/slave application where CCP-master starts communication by sending commands to a slave node. There can be several slave nodes connected on a CAN bus. CCP uses generic commands for data acquisition and simple memory handling for calibration. These two resources are independent and can therefore be used simultaneously.
CCP has been designed to handle the restrictions and demands of both small 8-bits microcontrollers and ECUs with high performance. No extra hardware has to be connected to the ECU. The CCP driver is fully implemented in the software. A simple implementation of CCP only needs a small part of the available RAM, ROM and CPU time for execution. A simple implementation only need two CAN message identifiers, which can be set as low priority that does not disturb the ordinary traffic. If CCP is to be used from an ordinary PC, the same simple and low cost CAN interface which is used in microcontrollers can be used.
Generic commands
CCP uses generic commands, which are not node specific, to perform different functions in a slave node. As the commands are generic every node must have an individual station address. A logical connection between master and slave has to be set up before any commands can be sent. This connection persists until the master decides to connect to another slave node or until the master sends a disconnect command. After the connection the master controls all communication between master and salve. Every message from the master is followed by a reply message from the slave containing data or error codes.
CCP-specific CAN messages
CCP is built on the CAN 2.0B protocol. All messages are 8 bytes long.
Only two types of CAN messages is needed, CRO and DTO, one for each direction. The CRO (Command Recieive Object) messages are sent from master to slave and contain control commands. DTO (Data Transmission Object) messages are sent from slave to master. When a slave has received a CRO message it performs the given instructions and then answers with a DTO message containing a CRM (Command Return Message). The CRM code tells the master if the corresponding control command has been performed as planned or not.
The CAN identifiers used for the CRO and DTO messages are determined by a configuration file (“A2L file”, defined by the ASAM MCD 2MC/ASAP2 standard) which is used to configure the master. The configuration file may also contain information about the slave memory organization, which is useful for data acquisition and calibration. Since the CAN identifiers define the priority of the message it should be chosen in a way that does not disturb the ordinary traffic on the bus. CCP does not determine which byte order to use (Motorola or Intel) in general data transmission. There is an exception that states that the byte order for the station address used when establishing a connection between master and slave has to be Intel (LSB first).
Description of CRO messages
CRO messages are sent from master to slave and contain instructions. The first byte is a command code (CMD) which describes the purpose of the message. The second byte is a command counter (CTR) and is used for keeping track of the communication. The command counter is also expected to be sent in return in the DTO message from the slave. Bytes 2-7 are reserved for data parameters depending on the command code. A message is always 8 bytes long and bytes which are not defined are considered as do not care”.
Description of DTO messages
The DTO message is sent by the slave as a receipt of a received CRO message and it is also used for data acquisition. The first byte in the message is called PID (Packet ID). The value of the PID describes the message type. There are three types of messages:
Data acquisition (DAQ)
The master device can initiate and start data acquisition from the slave device. Data is sent from the slave with special DAQ-DTOs. The data bytes are organized in DAQ lists which consists of a number of ODT lists. An ODT list contains up to 7 pointers to memory addresses in the ECU where data is stored. Besides pointers to memory addresses a ODT-list can contain a address extension and the number of bytes to be sent. All slave devices don’t handle data elements longer than one byte and it is up to the master to solve this task by splitting up the data into single bytes.
DAQ-DTO consists of a PID and the data elements of which the memory pointers in the ODT list points at. The PID number (usually the same as the ODT list) has a value between 0 and 253 which means that there can be only 254 ODT lists simultaneously.
The CCP specification allows several DAQ lists, which can be simultaneously active. Transmission of DAQ lists is initiated by the master through a START_STOP command. Data bytes in the ODT lists are sampled in the slave device and then sent on the CAN bus in DAQ-DTOs. If a new START_STOP command is received by the slave before the ongoing DAQ cycle is finished, there are two ways to react. The new DAQ command is started and the ongoing is terminated or the ongoing cycle is finished and the new is ignored. There are advantages and disadvantages with both methods and the CCP specification doesn’t say which one to choose.
Commands
The following commands are included in the CCP specification. All commands don’t have to be implemented if the ability for calibration isn’t needed and are therefore marked as optional. Also GET_DAQ_SIZE, SET_DAQ_PTR, WRITE_DAQ, START_STOP (and START_STOP_ALL) are DAQ specific and don’t have to be implemented unless this resource is used. GET_SEED and UNLOCK are used to unlock CCP resources like data acquisition and calibration if they are protected by a key (password), which is optional.
Error handling
Depending on the error code from the slave and how critical it is, the master take different actions.
Error C0 is a warning and no action is taken. If error C1 occurs there is an error in the communication or the node sending it is busy. On error C1 the master should wait the ACK time, and then try to resend the message. This should be done two times. Error C2 might be a temporary power loss and can be solved by a re-initialization. Error C3 is irresolvable and the master should terminate the running session.
Cold Start” means that a new logical connection between master and slave is established with a CONNECT command and some further initialization.
Example of sequences
The examples describe commands to use, as master, for basic CCP communication.
Login session (Cold Start)
A typical connection between master and slave starts with a CRO containing a CONNECT command from the master. The slave should answer with a corresponding DTO. To make sure that both master and slave talks the same “language” a GET_CCP_VERSION command is sent from the master with the expected version number. If the version number sent in return from the slave matches, communication can proceed. For “plug ‘n play” compatible nodes EXCHANGE_ID command can be used for automatic session configuration, depending on station address. On command GET_SEED the slave node returns information about protection status (locked/unlocked) of resources (DAQ or Calibration). If, for some reason, a resource is locked it has to be unlocked before it can be used. To unlock a resource an UNLOCK command, with a “key” received in the GET_SEED DTO, has to be sent from the master. Before the login session is ended initialization of status bits are recommended, this is done with SET_S_STATUS command.
Calibration init session
This session description assumes that a login procedure has been performed. The first thing then would be to set the session status bit for calibration to “off” with SET_S_STATUS command. Thereafter the memory address containing the data to exchange is selected with SET_MTA command. To ensure that this memory address is available a BUILD_CHKSUM command is sent and an answer from the slave node that confirms this is expected. Thereafter the data byte(s) can be downloaded to the selected address. First a DOWNLOAD command is sent with the number of data bytes and the value of each byte. To actually perform the data exchange the SELECT_CAL_PAGE is sent. To indicate that calibration has started session status bit for calibration is set to “on” with SET_S_STATUS command.
DAQ init session
This session description assumes that a login procedure has been performed. The session status bit for DAQ is set to “off” with SET_S_STATUS. A DAQ list is selected with GET_DAQ_SIZE and the slave answers with the number of available ODTs. SET_DAQ_POINTER command selects which DAQ list, ODT table and element in ODT that should be written to. WRITE_DAQ command then assigns the memory address of the data parameter to the previous selected element. When all DAQ lists are filled as wanted the session status bit for DAQ is set to “on” using SET_S_STATUS. The transmission of a DAQ list is started with the START_STOP command. If several DAQ lists should be started at the same time and sent synchronously START_STOP_ALL command is used.
Areas of use
The most common area of use is in the automotive industry, where CAN is often used, but also in other industry where CAN is used. Conceivable areas of use include –
Click to view the CCP documents:
