Measurement and Calibration Protocol XCP – Fundamentals
Development engineers and technicians benefit from high-performance standards and tools for optimal parameterization of ECUs. Such standards and tools must enable flexible read and write access to variables or memory contents. The CAN Calibration Protocol (CCP) – an OEM-independent standard – was developed for this purpose back in the 1990s. At that time, CAN was the sole dominant system for in-vehicle networking.
As automotive electronics continued to develop, additional bus systems such as LIN, MOST and FlexRay came into use. Because it was restricted to the CAN bus, CCP reached its limits, and this led to the development of the XCP protocol.
Standardization by ASAM and Benefits
Like CCP, the "Universal Measurement and Calibration Protocol" (XCP) originated from the "Association for Standardization of Automation and Measuring Systems" (ASAM) and was standardized in the year 2003. Vector played a key role in its release.
The "X" stands for the variable and interchangeable transport layer. To satisfy needs for a universal communication solution in a wide variety of applications, the ASAM working group gave special attention to the following criteria:
Support of a variety of transport layers such as CAN, FlexRay, Ethernet, SPI, SCI, USB, etc.
Better resource utilization in the ECU (dynamic DAQ lists)
Synchronous data stimulation (bypassing)
Support of start-up measurement (Resume mode)
Optimized communication by block transfer
Polling of XCP functions available in the ECU (plug & play)
More precise measurement data acquisition by measuring time stamps in the ECU (Slave) (Slave)
As a two-layer protocol, it consistently splits the XCP protocol from the transport layers, and it takes a Single-Master/Multi-Slave approach.
Protocol Layer and Transport Layers
Subdivision of XCP into protocol layer and transport layer
XCP is capable of utilizing the same protocol layer based on different transport layers. This protocol is a universal measurement and calibration protocol that operates independently of the type of network that is used. ASAM defines the following standard transport layers (Status October 2016):
XCP on CAN and CAN FD
XCP on SxI (SPI, SCI)
XCP on Ethernet (TCP/IP and UDP/IP)
XCP on USB
XCP on FlexRay
Single-Master / Multi-Slave Concept
XCP communication model with CTO/DTO
The measurement and calibration system assumes the role of XCP master, while the ECU operates as a slave. The master and slave each communicate over the integrated XCP driver. There is an ECU description file (in A2L format) for each slave, which – among other things – specifies associations between symbolic variable names and their address ranges, physical meanings of the data and the checksum method used. The XCP master can read out all necessary information from these A2L description files.
In communication via XCP, a distinction is made between the "Command Transfer Object" (CTO) and the "Data Transfer Object" (DTO). For example, the master might send a command to the ECU over the bus by CTO, and the ECU acknowledges over the same pathway after executing the requested service. Available CTOs are: CMD (Command), RES (Response), ERR (Error), EV (Event) and SERV (Service Request Processor). The DAQ (Data Acquisition) and STIM (Stimulation) data transfer objects are used for event-driven reading of measurement variables from the XCP slave's memory or writing values to memory.
Measuring & Calibrating Throughout the Development Process
XCP Slaves can be used in many different runtime environments
In measuring and calibrating with XCP, the specific environment in which the code or model (Simulink, rapid prototyping hardware, HIL, SIL, etc.) is run is irrelevant. That is, in optimizing the control algorithms for the ECU, you can use one and the same tool, always performing similar work steps. This makes configurations, measurement data and description files usable and interchangeable throughout the development process.
An XCP Master, such as CANape, is capable of communicating with different XCP slaves simultaneously. They include:
ECUs or ECU prototypes
Measurement and calibration hardware such as debug interfaces or memory emulators
Rapid prototyping hardware
Software Debugging over XCP
In the ECU, the debugging interface (e.g. JTAG, DAP, ...) can be used both for debugging the software and for measuring and adjusting via XCP. Both use cases are important across all stages of ECU development. Up to now, the services have been used completely independently of each other. Switching between debugging and XCP proved to be cumbersome because different physical adapters had to be used.
By including the debugging use case in the XCP standard, new possibilities are available for using the debugging interface for all the use cases mentioned, without having to change hardware, or even in permanently installed ECUs in the vehicle.
The debugger software is connected via XCP on Ethernet to an XCP slave of the VX1000 hardware.
The VX1000 hardware offers several XCP slaves that allow simultaneous use of debugging, measurement and calibration. This maximizes the use of the ECU debugging interface and achieves optimal performance in all use cases. The PODs are connected to the ECU either via serial interfaces such as JTAG and DAP or via parallel data trace interfaces such as Aurora and RTP/DMM.
The debugger software and the MC tool are connected to the VX1000 base module via XCP on Ethernet.
Reference book "XCP – The Standard Protocol for ECU Development" describes fundamentals and the application areas of the XCP measurement and calibration protocol in detail. Request the printed version with 128 pages in format 168x238 mm. Or download the book in three digital versions as PDF, EPUB and MOBI.
Learn about the capabilities of the ASAM MCD-1 XCP standard. Duration of this video 63 minutes.
With full XCP support, Vector offers you the right solution at every point of the development process.
The XCP standard was developed with crucial input by Vector, whose extensive know-how and experience also flowed into comprehensive support of the measurement and calibration protocol:
CANape is primarily used for optimal parameterization (calibration) of electronic control units. You can calibrate parameter values during the system’s runtime and simultaneously acquire measured signals. The physical connection between CANape and the ECU is over XCP (for all standardized transport protocols like XCP on Ethernet, FlexRay, CAN, etc.) or over CCP.
The option .AMD/XCP extends CANoe by adding the ability to access ECU memory. Reading or writing to memory locations in the ECU is performed via the ASAM standardized XCP protocol (XCP on CAN, XCP onEthernet) or CCP protocol. Configuration is conveniently done with files in A2L format.
The VX1000 measurement and calibration hardware offers the option of equipping ECUs with an XCP-on-Ethernet interface. This involves connecting a Plug on Device (POD) to the ECU for direct access to the controller, e.g. over DAP, JTAG, Nexus, etc. The POD transmits the data to a base module, which operates as an XCP Slave and provides the data to the XCP Master on the PC over XCP on Ethernet.
Communication modules with separate transport layers for CAN, FlexRay and Ethernet
XCP Basic – free download, only contains basic XCP functions. Configuration of the XCP protocol and modification of the transport layer are performed manually in the source code. You need to integrate XCP Basic in your project yourself.