XCPFundamentals of Measurement and Calibration Protocol
- Beginning of the page
The XCP measurement and calibration protocol
XCP (Universal Measurement and Calibration Protocol) is an interface for read and write access to the memory of an ECU. Access to parameters and measured variables is address-oriented. The properties and memory addresses of these data are described in the A2L file format. The A2L file contains all the information required to enable memory access and to interpret the transmitted data.
XCP is designed as a master-slave solution. The controller contains a protocol driver that responds to memory access requests from the master. Various measurement and calibration tasks can be performed by different configurations of the XCP master without recompiling the ECU application code.
The method works universally and is not limited to embedded ECUs. XCP can be used to acquire measurement data and adjust parameters from any software application, such as a simulation application on a PC.
- Protocol standardized by ASAM, which is used in many tools
- Support of different transport layers such as CAN, CAN FD, FlexRay, Ethernet, etc.
- Optimized for minimum consumption of resources (memory and runtime in the ECU, bus load)
- Measurement is synchronous with the events. Timestamps in the ECU are also recorded
- Plug-and-play communication between master and slave by querying the available XCP functions in the slave
- Synchronous data stimulation in the ECU
- Support of start-up measurement (resume mode)
As a two-layer protocol, XCP consistently separates the protocol and transport layers from each other and uses a single-master/multi-slave concept.
The XCP protocol is based on a single-master/multi-slave concept
Protocol Layer and Transport Layers
Single-Master / Multi-Slave Concept
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
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.
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.
Video XCP Fundamentals
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's primary area of application is the acquisition of measurement data and optimal parameterization (calibration) of electronic control units. During system runtime, you adjust parameter values and acquire measurement signals at the same time. The physical connection between CANape and the ECU is established via XCP (for all standardized transport protocols such as XCP on Ethernet, CAN FD, FlexRay, etc.)|
|In order to use the functionality of CANape in the vehicle comfortably as a logger, we have matched CANape and an industrial computer||CANape log|
A complete tool chain for generating and managing the necessary A2L description files (ASAP2 Tool-Set and CANape with integrated ASAP2 Studio).
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 on Ethernet) or CCP protocol. Configuration is conveniently done with files in A2L format.
|The GL-Logger family is used worldwide as a fleet logger solution. With the help of the XCP option, you can not only record bus data, but also ECU data||GL Logger|
|The VX1000 measurement and calibration hardware offers the option of equipping controllers with an XCP-on-Ethernet interface. A plug-on device (POD) is connected directly to the controller on the ECU, e.g. via DAP, JTAG, Nexus, Aurora, etc. The POD transmits the data to a base module that acts as an XCP-on-Ethernet interface. The POD transmits the data to a base module that operates as an XCP slave and makes the data available to the XCP master via XCP on Ethernet.|
Communication modules with separate transport layers for CAN, FlexRay and Ethernet
|XCPlite - Lightweight implementation of the ASAM XCP Protocol Layer V1.4.||Visit the GitHub page|
|XCP Basic - free download, contains the XCP basic functions. The configuration of the XCP protocol and the adaptation of the transport layer is done manually in the source code|
XCP Professional – contains useful extensions to the ASAM specification and enables tool-based configuration. Available for Vector CANbedded basic software.
MICROSAR XCP – contains the functional features of XCP Professional and is based on AUTOSAR specifications. Available for Vector MICROSAR basic software.
The goal of the seminar is to explain the underlying mechanisms and models.
- Introduction to Fundamentals of the XCP Protocol
- Models for Synchronous Data Transfer
- Models for Calibrating
- Interface Specifications
- Special Aspects of the XCP Transport Layer
- Example Communication Sequences
XCP Reference Book
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.