ASAM MCD-1 XCP
History
Origin
XCP is based on the ASAM standard CAN Calibration Protocol (CCP). The first version 1.01 of CCP was standardized in 1995. 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. One disadvantage is that timestamping for measurement data is not available. Furthermore, some features were not specified very concisely, for example flash reprogramming.
In the early 2000s, calibration interfaces were developed using microcontroller specific debug adapters (JTAG) or SPI, which were commonly 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.
ASAM Standard
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 all leading tools in the measurement & calibration area support XCP.
Two reasons for the protocol’s success have been stability and backward-compatibility. Over the years, only extensions were added, which do not break the compatibility to earlier versions.
The version history of XCP currently consists of 4 releases:
XCP 1.0 (2003):
- 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):
- Addition of the transport layer for FlexRay.
XCP 1.2 (2013):
- Adition of the A2L-IF_DATA description for calculation of the estimated ECU resource consumptions.
XCP 1.3 (2015):
- Addition of the base standard features ECU States, Bypassing Error Handling and Time Correlation.
XCP 1.4 (2017):
- New DAQ mode: packed DAQ with reduced transmission of timestamp data, improvement of DAQ data consistency e.g. for multicore processors, slave enforced calibration page switching and resource state changes, additions due to ASAM MCD-1 POD.
XCP 1.5 (2017):
- New associated standard "Software Debugging over XCP" has been added to XCP, which allows to carry out typical debugging use cases without the need to connect a debug adapter to the ECU.
Motivation
ECU calibration is a mission critical task for the development of automotive ECUs. XCP avoids the need to create specific ECU implementations for specific calibration tasks. Essentially, the protocol supports all typical calibration tasks without the need to recompile to ECU application.
XCP ensures interoperability between calibration systems and ECUs. Two typical customer-supplier collaboration scenarios are supported:
- 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
Application Areas
XCP can be used in all stages of ECU development, 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, 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.
Besides measurement data acquisition and calibration use cases, XCP is also used for reprogramming in early stages of ECU development where the required diagnostic services have not been implemented yet.
Technical Content
Introduction
A key functionality of ASAM MCD-1 XCP is to enable read and write access to the memory of the ECU. Read access, commonly called "measurement" in the standard, lets users measure the time response of an internal ECU variable. 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 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.
The access is address-oriented 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 (i.e. “Give me the value of memory location 0x1234").
Write access, commonly called "calibration" in the standard, lets the user optimize parameters of the ECU's algorithms. 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 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 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 was designed with these main objectives:
- Minimal resource usage in the ECU
- Efficient communication
- Simple Slave implementation
- Plug-and-play configuration with just a small number of parameters
- Scalability: XCP is also very scalable in its implementation, it is not necessary to implement every command described by the standard
- Transferability: XCP can be implemented on major bus systems and is open for future bus systems
Communication Model
XCP is based on the Master-Slave principle. The ECU is the slave and the measurement & calibration tool is the master. A slave may only communicate with one master at any given time. On the other hand, the master can simultaneously communicate with many slaves.
XCP data is exchanged between the master and slave in a message-based way. The XCP packet is embedded in a frame of the transport layer (in the case of XCP on Ethernet with UDP in a UDP packet). The frame consists of three parts: the XCP header, the XCP packet and the XCP tail.
In the following figure, the XCP packet section inside the XCP message is shown in red. The XCP header and XCP tail depend on the transport protocol.
The XCP packet 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 begins with the Packet Identifier (PID).
The type of communication via XCP packets is subdivided into one range for commands (CTO) and one range for sending synchronous data (DTO).
The acronyms used here are short for:
| Command | Command Packet | Description |
|---|---|---|
| RES | Command Response Packet | positive response |
| ERR | Error | negative response |
| EV | Event Packet | asynchronous event |
| SERV | Service Request Packet | service request |
| DAQ | Data Acquisition | send periodic measured values |
| STIM | Stimulation | 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 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.
Standard Commands
The XCP standard commands establish and 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.
Some of the standard commands are:
- Set up Connection With Slave
- Disconnect From Slave
- Get Current Session Status From Slave
- Get Communication Mode Info
- Get Identification From Slave
- Request to Save to Non-volatile Memory
- Get Seed for Unlocking a Protected Resource
- Send Key for Unlocking a Protected Resource
- Set Memory Transfer Address in Slave
- Upload From Slave to Master
- Build Checksum Over Memory Range
Data Acquisition (Measurement)
Read-Service Based Data Acquisition (Polling)
To read the memory locations of interest, the simplest way to acquire measurement data from the ECU is to send (typically) periodic requests from the XCP master to the slave. 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 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, to use this DAQ mode requires 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 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 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, 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.
XCP provides the feature to “timestamp” the acquired measurement data sample. It is assumed that an ECU has an internal clock which can be used to timestamp the measurement data at the moment when it is transferred from the ECU memory to a transmission send buffer.
The commands used for DAQ configuration are:
- Set Pointer to ODT Entry
- Write Element in ODT Entry
- Set Mode for DAQ List
- Start/Stop/Select DAQ List
- Start/Stop DAQ Lists (Synchronously)
- Write Multiple Elements in ODT
- Read Element From ODT Entry
- Get General Information on DAQ Processor
- Get General Information on DAQ Processing Resolution
- Get Mode From DAQ List
- Get Specific Information for an Event Channel
- DTO CTR Properties
- Clear DAQ List Configuration
- Get Specific Information for a DAQ List
- Clear Dynamic DAQ Configuration
- Allocate DAQ Lists
- Allocate ODTs to a DAQ List
- Allocate ODT Entries to an ODT
STIM Data Transmission
The STIM feature is very similar to DAQ, 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.
A STIM configuration is set up using exactly the same commands as a DAQ measurement configuration.
Time Correlation
XCP offers services to read the current value of the XCP slave clock of the ECU. This enables the calibration tool to correlate measurement data from different ECUs when displaying them together in one graphical chart. The command to get the XCP slave clock is GET_DAQ_CLOCK_FROM_SLAVE.
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. Today, there is a strong need for reliable synchronization accuracy in the single-digit microsecond range or even below that.
As a consequence, the protocol and transport layer specifications have been extended thoroughly with the advanced time correlation technique. As a central improvement, an XCP master is now able to obtain a detailed view of the clock system related to an XCP slave, i.e. the number of different clocks and their characteristics. Along with three basic techniques, advanced time correlation offers all the features needed to improve time synchronization significantly.
The first technique uses XCP native methods to improve time synchronization. The basic idea of this technique is to generate an XCP master initiated event (GET_DAQ_CLOCK_MULTICASTcommand) that simultaneously occurs at the XCP slaves connected to one transport layer. Each XCP slave has to sample its timestamps at the moment when this event occurs. The initiation of the event is thereby carried out periodically by an XCP master. This approach allows correlating the XCP slave’s timestamps among each other, eliminating the need of knowing the XCP master time as the global reference time. To obtain best accuracy, two requirements have to be satisfied:
Participating slaves have to sample their timestamps instantaneously with the occurrence of the event.
The latency between the XCP master and the participating XCP slaves should be the same to ensure a simultaneous occurrence of the XCP master initiated event at each XCP slave.
The generation of the XCP master initiated event that has to occur simultaneously at the XCP slaves requires broadcast-like mechanism. The method of generating such a broadcast message might be specific for each transport layer and is consequently part of a transport layer specification.
Due to the broadcast characteristic of the GET_DAQ_CLOCK_MULTICAST command and the fact that the command has to be understood as an XCP master initiated event, the processing of this command differs to classical commands. Instead of sending a positive response as the counterpart to the XCP master initiated command, an XCP slave supporting this feature reacts on aGET_DAQ_CLOCK_MULTICAST command by sending information relevant for time correlation as part of an EV_TIME_SYNC event packet to its XCP master. Therefore, the EV_TIME_SYNCevent packet has been significantly extended.
To ensure backward compatibility, the legacy formats for EV_TIME_SYNC events as well as the response to GET_DAQ_CLOCK command have to be used after connect. An XCP master supporting the advanced time correlation technique may enable the needed features in an XCP slave using the response format (RESPONSE_FMT) flag in SET_PROPERTIES of the TIME_CORRELATION_PROPERTIES command. Once the advanced time correlation features have been enabled, the XCP slave shall use the extended response formats for these messages.
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 first needs to know that the timestamps sent by an XCP slave are synchronized to a grandmaster clock at all. 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.
Therefore, each clock known to the XCP slave features a unique identifier. When a clock is synchronized/syntonized to a grandmaster clock, the slave’s clocks’ attributes have to be updated to reflect this state change. Based on the information of the XCP slave’s synchronization state and the information to which grandmaster clock the clock is synchronized to – by evaluating the unique clock identifiers – the XCP master is able to determine hierarchies of synchronized clocks.
The third technique addresses the requirements of resource limited XCP slaves that do not offer the possibility to synchronize clocks. In such a use case, the XCP slave can offer timestamp tuples to the XCP master, i.e. its local timestamp and the timestamp of the globally synchronized clock that was valid when the local timestamp was read. Based on this technique, the XCP master is aware of the relation between clocks of the XCP slave, and finally is able to perform precise clock correlation within the XCP master.
[1] Two clocks are synchronized to a specified uncertainty if they have the same epoch and their measurements of the time of a single event at an arbitrary time differ by no more than that uncertainty.
[2] Two clocks are syntonized if the duration of the second is the same on both. They may or may not share the same timestamp unit/timestamp size tuple. They may or may not share the same epoch.
Calibration (CAL)
ECU parameters are constant parameters that are adjusted and optimized during the development of the ECU or an ECU variant. This is an iterative process, in which the optimal value of a parameter is found by repeated measurements and changes. To make parameters modifiable at runtime during ECU’s development, additional RAM memory is needed.
The most frequently used approach to modifying parameters at runtime (“online calibration”) is to create the parameters in the available RAM memory.
C code example:
#pragma section “RAM_Parameter” 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. 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.
From the perspective of the ECU software, calibration parameters in RAM are unchangeable, i.e. the application itself does not change them. Many compilers discover this fact by code analysis and simply optimize the necessary RAM memory space away. Normally, it is therefore also necessary to prevent the compiler from optimizing by using the “volatile” attribute.
From the perspective of the calibration tool, the RAM area in which the parameters are located is referred to as calibration RAM (memory that can be calibrated).
The basic commands to access ECU memory are:
- Download From Master to Slave
- Download From Master to Slave (Block Mode)
- Download From Master to Slave (Fixed Size)
- Download From Master to Slave (Short Version)
- Modify Bits
ECU Memory Layout
The logical memory layout of the ECU (XCP slave) is described by objects called memory segments. 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). 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.
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.
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
Bypassing
Bypassing can be implemented by simultaneously making use of Synchronous Data Acquisition and Synchronous Data Stimulation (STIM). For Bypassing, at least two DAQ lists are required for transferring data between the ECU and the bypassing tool, i.e. one DAQ list for reading variables (Data Acquisition) and one DAQ list for writing variables (STIM). Furthermore, specific event channels are required, which control the bypassing process.
The figure shows an example of a simple bypass that uses a DAQ event channel and a STIM event channel. In the ECU, the inputs of the bypass function are sampled and sent to the bypassing tool as DAQ data before the original function is executed. Typically, the inputs of the bypass function are identical to the inputs of the original function. Once the bypassing tool receives the DAQ data triggers, it starts the execution of the bypass function. The output of the bypassing function is then sent back to the ECU as STIM data. Meanwhile, the ECU finished the execution of the original function. The STIM data is fed back to the ECU, typically by overwriting the outputs of the original function. This bypassing process runs in real-time. Consequently, the bypassing tool including the DAQ and STIM communication must execute in at least the same time than the ECU executes the original function.
The adaption of the ECU code to support a bypass is called a bypass hook. For safety reasons, a bypass hook may need to be activated before it is functional. The mechanism to enable a bypass hook is implementation-specific and not part of the XCP standard. If required, bypass hooks can be activated using means of XCP, e.g. by writing to a specific calibration parameter.
Flash Programming (PGM)
Flashing means writing data into an area of flash memory. Writing data into Flash requires precise knowledge of the ECU memory layout. 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.
Flashing can be implemented by a method that is called “flash kernels”. A flash kernel is executable code that is sent to the Slave’s RAM area and is then executed to carry out the actual flash process. The kernel handles the communication with the XCP Master and access to the Flash memory. It might contain the algorithm that is responsible for erasing the flash memory. For security and space reasons, this code is typically not stored permanently in the ECU’s flash memory.
The flash process with XCP is roughly subdivided into three areas:
- Preparation (e.g. for checking versions to avoid that unsuitable content is written to memory)
- Execution (the new content is sent to the ECU and written to memory)
- Post-processing (e.g. checksum checking, etc.)
Anyone who compares the flashing operation of XCP with flashing over diagnostic protocols will realize that the process-specific elements, such as serial number handling with metadata, have rather limited functionality. The standard is mainly used during development and does not cover the more complex process steps that are necessary in end-of-line flashing. Therefore, when using XCP for flashing the memory of an ECU, it is important to determine whether the content that is to be written to memory is relevant to the ECU. There are no special commands for version checking or other safety features in XCP that would avoid writing invalid content to the ECU.
The programming commands are:
- Indicate the Beginning of a Programming Sequence
- Clear a Part of Non-volatile Memory
- Program a Non-volatile Memory Segment
- Indicate the End of a Programming Sequence
- Get General Information on PGM Processor
- Get Specific Information for a SECTOR
- Prepare Non-volatile Memory Programming
- Set Data Format Before Programming
- Program a Non-volatile Memory Segment (Block Mode)
- Program a Non-volatile Memory Segment (fixed size)
- Program Verify
ECU States
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.
This concept is based on the already existing resource definition of the XCP specification with four different resource categories CAL/PAG, DAQ, STIM and PGM which are represented in the resource information and is available via the CONNECT response. The RESOURCE parameter bit field defines which resources are available in general, and the ECU state defines which resources are currently active.
XCP offers two mechanisms to provide the current ECU state to the XCP master:
- Mandatory: The XCP slave reports the current state to the XCP master in the response to the GET_STATUS command.
- Optional: If the XCP slave supports asynchronous event messages, it can use the event EV_ECU_STATE_CHANGE to inform the XCP master about a state change and the new STATE_NUMBER. The XCP slave sends the event message to the XCP master once. With the next GET_STATUS request the XCP master receives the STATE_NUMBER again.
With both mechanisms the XCP master receives the current STATE_NUMBER. The meaning of the specific state is defined in XCP IF_DATA section of the A2L file.
For the resource DAQ, STIM and PGM it is possible to define that these resources are active or not active. The CAL/PAG resource can be described with a higher granularity within MEMORY_ACCESS sections. The reason for this is that it could happen that the memory, which is the base for the calibration, is not completely located in the ECU or in the XCP slave. It could happen that only some parts of the memory are accessible for certain states. Therefore it is possible to define which segment / page of the memory is read- and/or writeable in a specific state.
The MEMORY_ACCESS definition is not needed if the resource CAL/PAG is not available for a specific state. The page access definition of a memory segment is the base for this concept. AnECU_STATE keeps or restricts this access for the given page. The restrictions concerning switching XCP and/or ECU pages are defined by the MEMORY_SEGMENT section of the A2L file.
Transmission of Asynchronous ECU Events
The slave can inform the master of an asynchronous event by sending an Event Packet (EV). The implementation of this feature is optional. It enables the slave to report a disturbance, such as the failure of a specific functionality.
The following asynchronous events are defined:
- Start in Resume Mode
- End of DAQ Clearing
- End of DAQ Storing
- End of CAL Storing
- Request to Restart Time-out Detection
- Indication of DAQ Overload
- Indication of Autonomous Disconnect
- Transfer of Timestamp and Synchronization
- Indication of Timeout at STIM
- Entering Sleep Mode
- Leaving Sleep Mode
- ECU state changed
- User-defined Event
- Transport Layer Specific Event
ECU Description
Using the ASAM standard MCD2-MC (also known as ASAP2), the XCP slave interface of an ECU can be modeled by the IF_DATA sections. XCP specifies the XCP IF_DATA section using the ASAP2 Meta Language (AML). The XCP IF_DATA contains sections which describe:
- Communication parameters (for example communication timeouts, CAN-IDs for communications, etc.)
- Implemented service commands
- XCP slave resources for the features DAQ, STIM, CAL, PAG and PGM
The XCP IF_DATA is structured into:
- Common parameters, describing the protocol layer and the available features
- The transport layers.
The calibration tool uses this information to establish communication, visualize the implemented XCP features and informs the calibration engineer about ECU resource limitations.
A typical task is the configuration of data acquisition. Using the IF_DATA information, the calibration tool shows the available XCP measurement events. The user configures the sampling rate for a signal by assigning an XCP measurement event. Furthermore the calibration tool is able to display the DAQ resource consumption, i.e. how many DAQ space is currently used, and how many signals may be additionally configured.
Relation to Other Standards
ASAM XCP is closely related to ASAM MCD-2-MC (also known as ASAP2), which is a description format for internal ECU variables. The ECU specific protocol parameters are described by the ASAP2 Meta Language within so called interface descriptions.
XCP on FlexRay requires the information of the FlexRay network cluster the ECU is part of. The “XCP on FlexRay” IF_DATA section references the FIBEX file (ASAM MCD-2 NET) and the network cluster to get knowledge of the FlexRay communication parameters.
XCP is closely related to the XCP BSW module specification of AUTOSAR 4.0, which actually implements the protocol stack and defines an RTE interface for sampling XCP measurement data.
Industry Adoption
All major calibration tool supplier support XCP, typically for all bus systems supported by the standard. The tools are used for measurement, rapid prototyping and calibration throughout all development phases of an ECU. Another common usage scenario for XCP is data logging for fleet testing or other post-production investigation activities, where data loggers need read-only access to data on ECUs. .
Moreover, some tool vendors use the opportunity of XCP for "Plug & Play" of measurement tools via reading out the XCP configuration (ASAP2) via XCP.
As mentioned above, XCP is integrated into the AUTOSAR basic software architecture. Basic software module vendors offer AUTOSAR-compliant XCP implementations.
Besides the use in automotive development, XCP is also used in other areas such as development of rail systems, combustion chain saws and other applications that make use of embedded controllers.
List of Deliverables
The standard includes the following deliverables:
- Base Standard
- Standard document for the base standard
- Standard documents for the associated standards
- XCP on CAN and CAN FD
- XCP on FlexRay
- XCP on Ethernet (UDP and TCP/IP)
- XCP on SxI (serial communication links)
- XCP on USB
- ASAP2 Meta language declarations for the ECU specific protocol parameters
- A sample source code package for the implementation of a Seed&Key DLL
Further Reading
- XCP – The Standard Protocol for ECU Development; Andreas Patzer; Rainer Zaiser; Vector Informatik; 2013; www.vector.com/xcp-book
- Analyzing AUTOSAR ECU Software with XCP; Patrick Markl; Stefan Albrecht; 2011; Hanser Automotive
Follow us on
MEET US AT THE
07. - 08.10.2021
Online Meeting
Get an update on current ASAM activities. Meet our management online and discuss with us your needs and requirements.
Register
