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
Subdivision of XCP into protocol layer and transport layer
The data transport takes place via different transport layers. The following transport layers are particularly relevant in the automotive sector:
XCP on CAN and CAN FD
XCP on SxI (SPI, SCI)
XCP on Ethernet (TCP/IP and UDP/IP)
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.
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.
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.)
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 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.
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.