Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

The ASAM MCD-1 XCP (Universal Measurement and Calibration Protocol) standard defines a bus-independent, master-slave communication protocol to connect ECUs with calibration systems. XCP is short for Universal Measurement and Calibration Protocol. The primary purpose of XCP is to adjust internal parameters and acquire the current values of internal variables of an ECU. The first letter X in XCP expresses the fact that the protocol is designed for a variety of bus systems. The standard consists of a base standard, which describes memory-oriented protocol services without direct dependencies on specific bus systems. Several associate standards contain the transport layer definitions for CAN, FlexRay, Ethernet (UDP/IP and TCP/IP), serial links (SPI and SCI) and USB.

The ASAM MCD-1 XCP accesses standard defines the access to parameters and measurement variables in a memory address oriented wayvariables using memory addresses. The properties and memory addresses of this data are described in the A2L-file format, which is standardized through the ASAM MCD-2 MC standard. The A2L-file contains all the information necessary to access and correctly interpret the data that is transmitted via the XCP protocol. This means that A2L file therefore provides access to a specific parameter or variable does not , without the need to be have hardcoded into access in the ECU application software. In other words, the ECU contains only a generic XCP-protocol stack, which responds to memory access 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 application code.

ASAM MCD-1 XCP was designed with two main objectives. FirstlyFirst, to impact the ECU to reduce the high requirements on ECU resources, such as CPU load, RAM consumption and flash memory, for the XCP slave in a minimal way, and secondly, . Second, to achieve a maximal data transmission rate over the communication link and to reduce the impact on bus communication as much as possible. The standard also describes the organization of the ECU memory segments used by the ECU software. This description allows memory-type specific access. It  XCP additionally describes the ECU interface for data read and write access.

ASAM MCD-1 XCP is an established and mature standard since 2003 and . XCP is used by both OEMs and ECU manufacturers. Compliance to ASAM MCD-1 XCP reduces the variety of calibration systems as well as avoiding the systems and avoids the need to create specific ECU implementations for specific application tasks.  ASAM MCD-1 XCP originates from the predecessor standard ASAM MCD-1 CCP, which is a measurement and calibration protocol specific to the CAN bus.

TitleUniversal Measurement and Calibration Protocol

Current Version

Release Date01.05.2015
DownloadASAM MCD-1 XCP V1.3.0
Application Areas
  • Calibration of ECU parameters

  • Measurement of ECU variables

  • Stimulation of ECU variables
  • ECU programming

Specification Content

  • Protocol specification
  • Interface specification

File Formats



XCP is based on the ASAM standard CAN Calibration Protocol (CCP). The first version 1.01 of CCP was standardized in 1995, the . 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, such as no timestamping . One disadvantage is that timestamping for measurement data is not available. Furthermore many details were , some features were not specified very concisely, for example flash reprogramming.

In the early 2000s, calibration interfaces were developed , which used microcontroller using microcontroller specific debug adapters (JTAG) or SPI, which were commonly available at 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 by . Basically all leading tools in the measurement & calibration area support XCP.

One reason Two reasons for the protocol’s success may have been its stability and backward-compatibility.  Over Over the years, only extensions were added, which do not break the compatibility to earlier versions.


  • Specification of the base standard features measurement & calibration, synchronous stimulation, page switching, reprogramming.

  • Specification of the transport layers for CAN, Ethernet (UDP and TCP/IP), SPI and USB.

XCP 1.1 (2008):

  • The Addition of the transport layer for FlexRay has been added.

XCP 1.2 (2013):

  • The Adition of the A2L-IF_DATA description for calculation of the estimated ECU resource consumptions has been added.

XCP 1.3 (2015):

  • The Addition of the base standard features ECU States, Bypassing Error Handling and Time Correlation have been added.

Contributors are Accurate Technologies Inc., CompactDynamics GmbH, Daimler AG, dSPACE GmbH, ETAS GmbH, Robert Bosch GmbH, Siemens VDO Automotive AG, Vector Informatik GmbH, Continental Corporation AG, RA Consulting GmbH and CSM GmbH.


  • an OEM calibrates a vehicle consisting of multiple ECUs from different suppliers

  • a supplier provides its ECU to OEMs, and the OEMs use different calibration systems


XCP can be used in all stages of ECU development, like function  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, it  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.


A key functionality of ASAM MCD-1 XCP is to enable read and write access to the memory of the ECU. Read access lets , commonly called "measurement" in the standard, lets users measure the time response of an internal ECU variable. This access is also commonly called "measurement" in the context of this standard. 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 allows 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. This is referred to as event-synchronous measurements.

The access is address-oriented , which means 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: slave (i.e. “Give me the value of memory location 0x1234”0x1234").

Write access lets the , commonly called "calibration" in the standard, lets the user optimize parameters of the ECU's algorithms. This access is also commonly called "calibration" in the context of this standard.  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 and 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 through 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.


Floating box

XCP message format


The XCP packet itself 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 Field begins with the Packet Identifier (PID).



Table Plus


The acronyms used here are short for:

CommandCommand PacketDescription


Command Response Packet

  • positive response



  • negative response


Event Packet

  • asynchronous event
SERVService Request Packet
  • service request
DAQData Acquisition
  • send periodic measured values
  • 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 always 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 close 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.


Read-Service based data acquisition (Polling)

The To read the memory locations of interest, the simplest way to acquire measurement data from the ECU is just sending is to send (typically) periodic requests by requests from the XCP master to the slave in order to read the memory locations for the measurement signals the user is interested in. 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 the 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: The , to use this DAQ mode requires code instrumentation of 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 them in 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 knowledge 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, it might  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. 


The STIM feature is very similar to DAQ, it just  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.


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. NowadaysToday, there is a strong need for reliable synchronization accuracy in the single-digit microsecond range or even below that.


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[1] or syntonized[2] to a grandmaster clock. In such a use case, the XCP master firstly first needs to know that the timestamps sent by an XCP slave are synchronized to a grandmaster clock at all. Secondly 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.


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. This is 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.


ECU Memory Layout

The logical memory layout of the ECU (XCP slave) is described by objects called memory segments. They have  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). This offers 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.

Page Switching (PAG)

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. 

Floating box

Memory segments and pages

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.

It has also to be mentioned that this 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:

  • Set Calibration Page
  • Get Calibration Page
  • Get General Information on PAG Processor
  • Get Specific Information for a SEGMENT
  • Get Specific Information for a PAGE
  • Set Mode for a SEGMENT
  • Get Mode for a SEGMENT
  • Copy Page


Flashing means writing data into an area of flash memory. This requires  Writing data into Flash requires precise knowledge of the ECU memory layout. A flash 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.


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.


Back to Top