XCP is based on the ASAM standard CAN Calibration Protocol (CCP). The first version 1.01 of CCP was standardized in 1995. The latest and current version 2.01 of CCP was finished in 1999. Though still used in many existing ECU implementations, CCP has some disadvantages. One disadvantage is that timestamping for measurement data is not available. Furthermore, some features were not specified very concisely, for example flash reprogramming.
In the early 2000s, calibration interfaces were developed using microcontroller specific debug adapters (JTAG) or SPI, which were commonly available for microcontrollers. These interfaces provided much higher data transmission rates than the highest CAN baud rate of 1 MBaud and were attached to a calibration system (typically a PC) via Ethernet. Therefore, the need for an abstraction of CCP was recognized.
The initial version of XCP has been developed in 2003.It was designed for use in the automotive industry, primarily for the areas of ECU development, calibration and testing. Since then, the protocol has widely spread and is supported by many tools on the market. Basically all leading tools in the measurement & calibration area support XCP.
Two reasons for the protocol’s success have been stability and backward-compatibility. Over the years, only extensions were added, which do not break the compatibility to earlier versions.
The version history of XCP currently consists of 4 releases:
XCP 1.0 (2003):
XCP 1.1 (2008):
XCP 1.2 (2013):
XCP 1.3 (2015):
XCP 1.4 (2017):
XCP 1.5 (2017):
ECU calibration is a mission critical task for the development of automotive ECUs. XCP avoids the need to create specific ECU implementations for specific calibration tasks. Essentially, the protocol supports all typical calibration tasks without the need to recompile to ECU application.
XCP ensures interoperability between calibration systems and ECUs. Two typical customer-supplier collaboration scenarios are supported:
XCP can be used in all stages of ECU development, such as function development, ECU calibration and testing of ECUs. As XCP is able to realize high data rates and short measurement cycle times in the microsecond range, XCP is very helpful when analyzing the dynamic behavior of electromechanical systems relevant for automotive use cases such as engine or transmission systems or electric drives.
Besides measurement data acquisition and calibration use cases, XCP is also used for reprogramming in early stages of ECU development where the required diagnostic services have not been implemented yet.
A key functionality of ASAM MCD-1 XCP is to enable read and write access to the memory of the ECU. Read access, commonly called "measurement" in the standard, lets users measure the time response of an internal ECU variable. ECUs are systems with discrete time behavior, whose variables only change at specific time intervals. One of the great strengths of XCP lies in acquiring measured values from RAM only at specific periodic points of time or at specific events. This time or event driven access, commonly called "event-synchronous measurement", allows users to directly evaluate the ECU's behavior over time with recorded values from internal variables and external sensors.
The access is address-oriented meaning the communication between master (i.e. the measurement & calibration tool) and slave (i.e. the ECU) references addresses in memory. So, the measurement of a variable is essentially implemented as a request of the master to the slave (i.e. “Give me the value of memory location 0x1234").
Write access, commonly called "calibration" in the standard, lets the user optimize parameters of the ECU's algorithms. The calibration of a parameter is essentially implemented as a request of the master to the slave (i.e. “Set the value at address 0x9876 to 5”).
An XCP slave does not necessarily need to be an ECU. The XCP protocol may be implemented in different environments. Two examples are either from a model-based development environment to hardware-in-the-loop or software-in-the-loop environments to hardware interfaces that are used to access ECU memory via debug interfaces, such as JTAG, NEXUS and DAP.
The properties and memory addresses of parameters are described in the A2L-file format, which is standardized with ASAM MCD-2 MC. This means that access to a specific parameter does not need to be hardcoded into the ECU application. In other words, the ECU contains only a generic XCP slave protocol stack, which responds to memory access service requests from the calibration system. Different calibration and measurement tasks can be performed by different configurations of the calibration system without recompiling and reprogramming the ECU software.
XCP was designed with these main objectives:
XCP is based on the Master-Slave principle. The ECU is the slave and the measurement & calibration tool is the master. A slave may only communicate with one master at any given time. On the other hand, the master can simultaneously communicate with many slaves.
XCP data is exchanged between the master and slave in a message-based way. The XCP packet is embedded in a frame of the transport layer (in the case of XCP on Ethernet with UDP in a UDP packet). The frame consists of three parts: the XCP header, the XCP packet and the XCP tail.
In the following figure, the XCP packet section inside the XCP message is shown in red. The XCP header and XCP tail depend on the transport protocol.
The XCP packet is independent of the used transport protocol. It always contains three components: “Identification Field”, “Timestamp Field” and the payload in the “Data Field”. Each Identification Field begins with the Packet Identifier (PID).
The type of communication via XCP packets is subdivided into one range for commands (CTO) and one range for sending synchronous data (DTO).
The acronyms used here are short for:
|RES||Command Response Packet||positive response|
|EV||Event Packet||asynchronous event|
|SERV||Service Request Packet||service request|
|DAQ||Data Acquisition||send periodic measured values|
|STIM||Stimulation||periodic stimulation of the slave|
Commands are exchanged via CTOs (Command Transfer Objects). For example, the master initiates contact in this direction. The slave must respond to a CMD with RES or ERR. The other CTO messages are sent asynchronously. The Data Transfer Objects (DTO) are used to transfer synchronous measurement and stimulation data.
The XCP standard commands establish and terminate communication, identify the ECU implementation (version check), unlock protected resources, obtain the current session state, and provide read access to the ECU memory. In order to speed up memory downloads, the calibration system can cache the calibration memory and optimize the memory downloads by sending only the differing memory parts of a parameter set. This requires that the cache and the ECU memory must be identical. To ensure this, XCP specifies commands for calculation of memory checksums.
Some of the standard commands are:
Read-Service Based Data Acquisition (Polling)
To read the memory locations of interest, the simplest way to acquire measurement data from the ECU is to send (typically) periodic requests from the XCP master to the slave. The drawback to these periodic requests is that at least two messages are generated for each signal (command and response), and the acquisition time is not synchronized with the cycle time of the ECU tasks that execute the control algorithms.
Synchronous Data Acquisition (DAQ)
To overcome these disadvantages of the polling mode, XCP offers the synchronous data acquisition mode. In the control flow of an ECU algorithm, XCP DAQ events can be defined by inserting a function call to the XCP slave protocol stack, which triggers the sampling of measurement data. In other words, to use this DAQ mode requires the ECU code to be instrumented.
Note: The AUTOSAR specification defines the XCP BSW module which implements the XCP protocol stack and the internal routines to trigger the sampling of measurement data.
When the algorithm in the slave reaches the location of such a sampling event, the XCP Slave collects the values of the measurement parameters, saves these values in a buffer and sends them to the master. This setup requires that the slave knows which variables should be measured for which event. The slave obtains this information during the DAQ configuration phase, where the master sends specific commands which define the requested measurement variables and their associated XCP events. After the completion of the configuration phase, the XCP master starts the measurement data acquisition, and the XCP slave sends the measurement data without further explicit read requests to the master.
An event does not have to be cyclic and time-equidistant. In the case of an engine controller, for example, the event might be angle-synchronous. This makes the time interval between two events dependent on the engine angular velocity. Singular events, such as arbitrary activations of a switch by the driver, are by no means equidistant in time.
XCP provides the feature to “timestamp” the acquired measurement data sample. It is assumed that an ECU has an internal clock which can be used to timestamp the measurement data at the moment when it is transferred from the ECU memory to a transmission send buffer.
The commands used for DAQ configuration are:
The STIM feature is very similar to DAQ, but works in the opposite direction. Using STIM, the calibration tool is able to overwrite values of variables of the control algorithm in a task synchronous way. This feature can be used to implement a bypass, where parts of the ECU's control algorithms are calculated outside the ECU by an external bypassing system, see the chapter about "Bypassing" below for further information.
A STIM configuration is set up using exactly the same commands as a DAQ measurement configuration.
XCP offers services to read the current value of the XCP slave clock of the ECU. This enables the calibration tool to correlate measurement data from different ECUs when displaying them together in one graphical chart. The command to get the XCP slave clock is GET_DAQ_CLOCK_FROM_SLAVE.
Due to limitations in the implementation of the XCP master and XCP slaves as well as limitations of the communication infrastructure, the achievable accuracy using the above mentioned legacy time correlation technique is limited. Today, there is a strong need for reliable synchronization accuracy in the single-digit microsecond range or even below that.
As a consequence, the protocol and transport layer specifications have been extended thoroughly with the advanced time correlation technique. As a central improvement, an XCP master is now able to obtain a detailed view of the clock system related to an XCP slave, i.e. the number of different clocks and their characteristics. Along with three basic techniques, advanced time correlation offers all the features needed to improve time synchronization significantly.
The first technique uses XCP native methods to improve time synchronization. The basic idea of this technique is to generate an XCP master initiated event (GET_DAQ_CLOCK_MULTICASTcommand) that simultaneously occurs at the XCP slaves connected to one transport layer. Each XCP slave has to sample its timestamps at the moment when this event occurs. The initiation of the event is thereby carried out periodically by an XCP master. This approach allows correlating the XCP slave’s timestamps among each other, eliminating the need of knowing the XCP master time as the global reference time. To obtain best accuracy, two requirements have to be satisfied:
Participating slaves have to sample their timestamps instantaneously with the occurrence of the event.
The latency between the XCP master and the participating XCP slaves should be the same to ensure a simultaneous occurrence of the XCP master initiated event at each XCP slave.
The generation of the XCP master initiated event that has to occur simultaneously at the XCP slaves requires broadcast-like mechanism. The method of generating such a broadcast message might be specific for each transport layer and is consequently part of a transport layer specification.
Due to the broadcast characteristic of the GET_DAQ_CLOCK_MULTICAST command and the fact that the command has to be understood as an XCP master initiated event, the processing of this command differs to classical commands. Instead of sending a positive response as the counterpart to the XCP master initiated command, an XCP slave supporting this feature reacts on aGET_DAQ_CLOCK_MULTICAST command by sending information relevant for time correlation as part of an EV_TIME_SYNC event packet to its XCP master. Therefore, the EV_TIME_SYNCevent packet has been significantly extended.
To ensure backward compatibility, the legacy formats for EV_TIME_SYNC events as well as the response to GET_DAQ_CLOCK command have to be used after connect. An XCP master supporting the advanced time correlation technique may enable the needed features in an XCP slave using the response format (RESPONSE_FMT) flag in SET_PROPERTIES of the TIME_CORRELATION_PROPERTIES command. Once the advanced time correlation features have been enabled, the XCP slave shall use the extended response formats for these messages.
The use of the second technique presumes the availability of an XCP unrelated time synchronization technique, e.g. the Precision Time Protocol (PTP) as defined in the IEEE 1588 standard (IEEE Standard for a precision clock synchronization protocol for networked measurement and control systems, Feb. 2009). In this use case it is assumed that the XCP slave’s clock is either synchronized or syntonized to a grandmaster clock. In such a use case, the XCP master first needs to know that the timestamps sent by an XCP slave are synchronized to a grandmaster clock at all. Second, it is necessary to also obtain the information, to which grandmaster clock the XCP slave is synchronized/syntonized to. This information is required to handle systems with more than one grandmaster clock. With introduction of the advanced time correlation technique, XCP nodes are aware of time synchronization carried out through well-established, XCP unrelated standards.
Therefore, each clock known to the XCP slave features a unique identifier. When a clock is synchronized/syntonized to a grandmaster clock, the slave’s clocks’ attributes have to be updated to reflect this state change. Based on the information of the XCP slave’s synchronization state and the information to which grandmaster clock the clock is synchronized to – by evaluating the unique clock identifiers – the XCP master is able to determine hierarchies of synchronized clocks.
The third technique addresses the requirements of resource limited XCP slaves that do not offer the possibility to synchronize clocks. In such a use case, the XCP slave can offer timestamp tuples to the XCP master, i.e. its local timestamp and the timestamp of the globally synchronized clock that was valid when the local timestamp was read. Based on this technique, the XCP master is aware of the relation between clocks of the XCP slave, and finally is able to perform precise clock correlation within the XCP master.
 Two clocks are synchronized to a specified uncertainty if they have the same epoch and their measurements of the time of a single event at an arbitrary time differ by no more than that uncertainty.
 Two clocks are syntonized if the duration of the second is the same on both. They may or may not share the same timestamp unit/timestamp size tuple. They may or may not share the same epoch.
ECU parameters are constant parameters that are adjusted and optimized during the development of the ECU or an ECU variant. This is an iterative process, in which the optimal value of a parameter is found by repeated measurements and changes. To make parameters modifiable at runtime during ECU’s development, additional RAM memory is needed.
The most frequently used approach to modifying parameters at runtime (“online calibration”) is to create the parameters in the available RAM memory.
C code example:
#pragma section “RAM_Parameter” const volatile float factor = 0.5;
This code defines the parameter “factor” as a RAM variable with the initial value 0.5. During compiling and linking of the code, memory space is reserved for the object “factor” in RAM and the associated RAM address appears in the linker-map file. The initial value 0.5 is stored in flash memory and at the relevant location in the hex file. The addresses of the initial values in flash memory are defined by parameterization of the linker, but they do not appear in the linker-map file.
During booting of the ECU, all RAM variables are initialized once with their initial values from flash memory. The initialization is usually executed in the start-up code of the compiler manufacturer and the application programmer does not need to be concerned with it. The application uses the values of parameters located in RAM and they can be modified via normal XCP memory accesses.
From the perspective of the ECU software, calibration parameters in RAM are unchangeable, i.e. the application itself does not change them. Many compilers discover this fact by code analysis and simply optimize the necessary RAM memory space away. Normally, it is therefore also necessary to prevent the compiler from optimizing by using the “volatile” attribute.
From the perspective of the calibration tool, the RAM area in which the parameters are located is referred to as calibration RAM (memory that can be calibrated).
The basic commands to access ECU memory are:
The logical memory layout of the ECU (XCP slave) is described by objects called memory segments. Memory segments have attributes which describe the content and access type to the parameters, for example DATA+RAM or CODE+FLASH. A segment is described using the ASAM MCD-2 MC keyword MEMORY_SEGMENT, which contains information like name, address, size and offsets for mirrored segments. The XCP specific information is inside an IF_DATA section, such as page definitions.
Parameters which are adjustable by the calibration system have to be located in data memory segments that are physically located in RAM. Addresses of parameters and memory segments are logical addresses which may be mapped to physical memory addresses by means of memory management units (MMU). These MMUs offer the possibility to adjust parameters located in a flash memory segment by remapping (using an address translation) to a physical RAM area. It is not necessary to change the ECU control algorithm implementation because it uses logical addresses to access parameters.
XCP introduces the concept of pages which make the implemented address translations accessible for the XCP Page Switching service commands. If these services are implemented, the calibration tool is able to control the active page. If it switches a memory segment from a Flash page to a RAM page, a parameter located in this memory segment can be adjusted during the execution of the control algorithm, also known as online calibration.
The access for the calibration tool and the ECU algorithm can be changed independently.
This access enables modifications of large parameters (e.g. maps) without jeopardizing the data consistency during write operations to the ECU memory. This consistency is realized by first switching the calibration tool access to the RAM page, then writing the data to the ECU and after that switching the ECU access to the RAM page. This solution requires of course, that the switching action is implemented as an atomic operation.
Note: This concept depends on the ECU controller features and the XCP slave implementation and may not be supported by all ECUs.
The page switching commands are:
Bypassing can be implemented by simultaneously making use of Synchronous Data Acquisition and Synchronous Data Stimulation (STIM). For Bypassing, at least two DAQ lists are required for transferring data between the ECU and the bypassing tool, i.e. one DAQ list for reading variables (Data Acquisition) and one DAQ list for writing variables (STIM). Furthermore, specific event channels are required, which control the bypassing process.
The figure shows an example of a simple bypass that uses a DAQ event channel and a STIM event channel. In the ECU, the inputs of the bypass function are sampled and sent to the bypassing tool as DAQ data before the original function is executed. Typically, the inputs of the bypass function are identical to the inputs of the original function. Once the bypassing tool receives the DAQ data triggers, it starts the execution of the bypass function. The output of the bypassing function is then sent back to the ECU as STIM data. Meanwhile, the ECU finished the execution of the original function. The STIM data is fed back to the ECU, typically by overwriting the outputs of the original function. This bypassing process runs in real-time. Consequently, the bypassing tool including the DAQ and STIM communication must execute in at least the same time than the ECU executes the original function.
The adaption of the ECU code to support a bypass is called a bypass hook. For safety reasons, a bypass hook may need to be activated before it is functional. The mechanism to enable a bypass hook is implementation-specific and not part of the XCP standard. If required, bypass hooks can be activated using means of XCP, e.g. by writing to a specific calibration parameter.
Flashing means writing data into an area of flash memory. Writing data into Flash requires precise knowledge of the ECU memory layout. Flash memory is subdivided into multiple sectors (physical sections) which are described by a start address and length. To distinguish them from one another, each of the sectors get a consecutive identification number. The information about the flash sectors is also part of the A2L file.
Flashing can be implemented by a method that is called “flash kernels”. A flash kernel is executable code that is sent to the Slave’s RAM area and is then executed to carry out the actual flash process. The kernel handles the communication with the XCP Master and access to the Flash memory. It might contain the algorithm that is responsible for erasing the flash memory. For security and space reasons, this code is typically not stored permanently in the ECU’s flash memory.
The flash process with XCP is roughly subdivided into three areas:
Anyone who compares the flashing operation of XCP with flashing over diagnostic protocols will realize that the process-specific elements, such as serial number handling with metadata, have rather limited functionality. The standard is mainly used during development and does not cover the more complex process steps that are necessary in end-of-line flashing. Therefore, when using XCP for flashing the memory of an ECU, it is important to determine whether the content that is to be written to memory is relevant to the ECU. There are no special commands for version checking or other safety features in XCP that would avoid writing invalid content to the ECU.
The programming commands are:
The idea of the ECU States concept in XCP is to make the XCP slave status more visible for the XCP master during the XCP session. Using this concept the slave is able to inform the XCP master about changes of the ECU state in the XCP slave. It is possible that certain resources can have an active or inactive state. An ECU state describes the status of all resources. In consequence the status of the slave can change more dynamically and would be still visible for the XCP master.
This concept is very important for the use case that the ECU and XCP slave are different instances and the XCP slave can run without an active ECU. In this use case a specific connection between protocol handler and ECU exists.
This concept is based on the already existing resource definition of the XCP specification with four different resource categories CAL/PAG, DAQ, STIM and PGM which are represented in the resource information and is available via the CONNECT response. The RESOURCE parameter bit field defines which resources are available in general, and the ECU state defines which resources are currently active.
XCP offers two mechanisms to provide the current ECU state to the XCP master:
With both mechanisms the XCP master receives the current STATE_NUMBER. The meaning of the specific state is defined in XCP IF_DATA section of the A2L file.
For the resource DAQ, STIM and PGM it is possible to define that these resources are active or not active. The CAL/PAG resource can be described with a higher granularity within MEMORY_ACCESS sections. The reason for this is that it could happen that the memory, which is the base for the calibration, is not completely located in the ECU or in the XCP slave. It could happen that only some parts of the memory are accessible for certain states. Therefore it is possible to define which segment / page of the memory is read- and/or writeable in a specific state.
The MEMORY_ACCESS definition is not needed if the resource CAL/PAG is not available for a specific state. The page access definition of a memory segment is the base for this concept. AnECU_STATE keeps or restricts this access for the given page. The restrictions concerning switching XCP and/or ECU pages are defined by the MEMORY_SEGMENT section of the A2L file.
The slave can inform the master of an asynchronous event by sending an Event Packet (EV). The implementation of this feature is optional. It enables the slave to report a disturbance, such as the failure of a specific functionality.
The following asynchronous events are defined:
Using the ASAM standard MCD2-MC (also known as ASAP2), the XCP slave interface of an ECU can be modeled by the IF_DATA sections. XCP specifies the XCP IF_DATA section using the ASAP2 Meta Language (AML). The XCP IF_DATA contains sections which describe:
The XCP IF_DATA is structured into:
The calibration tool uses this information to establish communication, visualize the implemented XCP features and informs the calibration engineer about ECU resource limitations.
A typical task is the configuration of data acquisition. Using the IF_DATA information, the calibration tool shows the available XCP measurement events. The user configures the sampling rate for a signal by assigning an XCP measurement event. Furthermore the calibration tool is able to display the DAQ resource consumption, i.e. how many DAQ space is currently used, and how many signals may be additionally configured.
ASAM XCP is closely related to ASAM MCD-2-MC (also known as ASAP2), which is a description format for internal ECU variables. The ECU specific protocol parameters are described by the ASAP2 Meta Language within so called interface descriptions.
XCP on FlexRay requires the information of the FlexRay network cluster the ECU is part of. The “XCP on FlexRay” IF_DATA section references the FIBEX file (ASAM MCD-2 NET) and the network cluster to get knowledge of the FlexRay communication parameters.
XCP is closely related to the XCP BSW module specification of AUTOSAR 4.0, which actually implements the protocol stack and defines an RTE interface for sampling XCP measurement data.
All major calibration tool supplier support XCP, typically for all bus systems supported by the standard. The tools are used for measurement, rapid prototyping and calibration throughout all development phases of an ECU. Another common usage scenario for XCP is data logging for fleet testing or other post-production investigation activities, where data loggers need read-only access to data on ECUs. .
Moreover, some tool vendors use the opportunity of XCP for "Plug & Play" of measurement tools via reading out the XCP configuration (ASAP2) via XCP.
As mentioned above, XCP is integrated into the AUTOSAR basic software architecture. Basic software module vendors offer AUTOSAR-compliant XCP implementations.
Besides the use in automotive development, XCP is also used in other areas such as development of rail systems, combustion chain saws and other applications that make use of embedded controllers.
The standard includes the following deliverables:
© 2019 ASAM e.V. All Rights Reserved