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.
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).
The acronyms used here are short for:
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 or syntonized 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.
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
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.