XCP ReferenceBook V1.0 EN
XCP ReferenceBook V1.0 EN
XCP ReferenceBook V1.0 EN
XCP
The Standard Protocol
for ECU Development
Table of Contents
Introduction
13
19
21
21
22
22
22
25
28
28
29
29
29
32
33
34
41
42
44
45
45
48
51
53
53
53
54
54
56
56
58
59
60
61
63
66
67
68
71
72
74
76
77
78
78
80
81
83
85
86
87
89
90
93
97
100
102
104
105
105
106
108
110
Introduction
Introduction
In optimal parameterization (calibration) of electronic ECUs, you calibrate parameter values
during the system runtime and simultaneously acquire measured signals. The physical connection between the development tool and the ECU is via a measurement and calibration protocol.
XCP has become established as a standard here.
First, the fundamentals and mechanisms of XCP will be explained briefly and then the application areas and added value for ECU calibration will be discussed.
First, some facts about XCP:
> XCP signifies Universal Measurement and Calibration Protocol. The X stands for the variable and interchangeable transport layer.
> It was standardized by an ASAM working committee (Association for Standardisation of Automation and Measuring Systems). ASAM is an organization of automotive OEMs, suppliers and
tool producers.
> XCP is the protocol that succeeds CCP (CAN Calibration Protocol).
> The conceptual idea of the CAN Calibration Protocol was to permit read and write access to
internal ECU data over CAN. XCP was developed to implement this capability via different
transmission media. Then one speaks of XCP on CAN, XCP on FlexRay or XCP on Ethernet.
> The primary applications of XCP are measurement and calibration of internal ECU parameters.
Here, the protocol offers the ability to acquire measured values event synchronous to processes in ECUs. This ensures consistency of the data between one another.
To visualize the underlying idea, we initially view the ECU and the software running in it as
a black box. In a black box, only the inputs into the ECU (e.g. CAN messages and sensor values) and the output from the ECU (e.g. CAN messages and actuator drives) are acquired. Details
about the internal processing of algorithms are not immediately apparent and can only be
determined from an analysis of the input and output data.
Now imagine that you had a look into the behavior of your ECU with every computation cycle. At
any time, you could acquire detailed information on how the algorithm is running. You would
no longer have a black box, but a white box instead with a full view of internal processes. That
is precisely what you get with XCP!
What contribution can XCP make for the overall development process? To check the functionality of the attained development status, the developer can execute the code repeatedly. In this
way, the developer finds out how the algorithm behaves and what might be optimized. It does
not matter here whether a compiled code runs on a specific hardware or whether it is developed
in a model-based way and the application runs in the form of a model.
A central focus is on the evaluation of the algorithm process. For example, if the algorithm is
running as a model in a development environment, such as Simulink from The MathWorks, it
is helpful to developers if they can also acquire intermediate results to their applications, in
order to obtain findings about other changes. In the final analysis, this method enables nothing other than read access to parameters so that they can be visualized and analyzed and all
of this at model runtime or retrospectively after a time-limited test run has been completed. A
write access is needed if parameterizations are changed, e.g. if the proportional component of a
Introduction
PID controller is modified to adapt the algorithm behavior to the system under control. Regardless of where your application runs focal points are always the detailed analysis of algorithm
processes and optimization by changes to the parameterization.
This generalization can be made: The algorithms may exist in any type of executable form (code
or model description). Different systems may be used as the runtime environment (Simulink,
as DLL on the PC, on a rapid prototyping platform, in the ECU etc.). Process flows are analyzed
by read access to data and acquisition of its time-based flow. Parameter sets are modified iteratively to optimize algorithms. To simplify the representation, the acquisition of data can be
externalized to an external PC-based tool, although it is understood here that runtime environments themselves can even offer analysis capabilities.
Runtime Environment
PC Tool
Communication
Application
Operating System
Figure 1:
Fundamental
communication
with a runtime
environment
The type of runtime environment and the form of communication generally differ from one
another considerably. The reason is that the runtime environments are developed by different
producers and are based on different solution approaches. Different types of protocols, configurations, measurement data formats, etc. make it a futile effort to try to exchange parameter sets and results in all development steps. In the end, however, all of these solutions can be
reduced to read and write access at runtime. And there is a standard for this: XCP.
XCP is an ASAM standard whose Version 1.0 was released in 2003. The acronym ASAM stands
for Association for Standardisation of Automation and Measuring Systems. Suppliers, vehicle
OEMs and tool manufacturers are all represented in the ASAM working group. The purpose of the
XCP working group is to define a generalized measurement and calibration protocol that can be
used independent of the specific transport medium. Experience gained from working with CCP
(CAN Calibration Protocol) flowed into the development as well.
XCP was defined based on the ASAM interfaces model. The following figure shows a measurement and calibration tools interfaces to the XCP Slave, to the description file and the connection to a higher-level automation system.
Introduction
Upper Level
Automation System
ASAM MCD 3MC
Measurement and
Calibration System
XCP Driver
ASAM
MCD 2MC
*.a2L
ECU Description File
XCP Driver
ECU
Figure 2:
The Interface Model
of ASAM
Interface 1: ASAM MCD-1 MC between the ECU and the measurement and calibration system
This interface describes the physical and the protocol-specific parts. Strictly speaking, a distinction was made between interfaces ASAP1a and ASAP1b here. The ASAP1b interface, however, never received general acceptance and for all practical purposes it has no relevance today.
The XCP protocol is so flexible that it can practically assume the role of a general manufacturerindependent interface. For example, today all measurement and calibration hardware manufacturers offer systems (xETK, VX1000, etc.) which can be connected via the XCP on Ethernet standard. An ASAP1b interface as it was still described for CCP is no longer necessary.
Interface 2: ASAM MCD-2 MC A2L ECU description file
As already mentioned, XCP works in an address-oriented way. Read or write accesses to objects
are always based on an address entry. Ultimately, however, this would mean that the user would
have to search for his ECU objects in the Master based on the address. That would be extremely
inconvenient. To let users work with symbolic object names, for example, a file is needed that
describes the relationship between the object name and the object address. The next chapter is
devoted to this A2L description file.
Interface 3: ASAM MCD-3 MC automation interface
This interface is used to connect another system to the measurement and calibration tool, e.g.
for test bench automation. The interface is not further explained in this document, because it is
irrelevant to understanding XCP.
10
Introduction
XCP is based on the Master-Slave principle. The ECU is the Slave and the measurement and calibration tool is the Master. A Slave may only communicate with one Master at any given time; on
the other hand, the Master can simultaneous communicate with many Slaves.
Master
Bus
Slave
Slave
Slave
Slave
Figure 3:
An XCP Master can
simultaneously
communicate with
multiple Slaves
To be able to access data and configurations over the entire development process, XCP must
be used in every runtime environment. Fewer tools would need to be purchased, operated and
maintained. This would also eliminate the need for manual copying of configurations from one
tool to another, a process that is susceptible to errors. This would simplify iterative loops, in
which results from later work steps are transferred back to prior work steps.
But let us turn our attention away from what might be feasible to what is possible today: everything! XCP solutions are already used in a wide variety of work environments. It is the intention
of this book to describe the main properties of the measurement and calibration protocol and
introduce its use in the various runtime environments. What you will not find in this book: neither the entire XCP specification in detailed form, nor precise instructions for integrating XCP
drivers in a specific runtime environment. It explains the relationships, but not the individual
protocol and implementation details. Internet links in the appendix refer to openly available
XCP driver source code and sample implementations, which let you understand and see how the
implementation is made.
Screenshots of the PC tool used in this book were prepared using the CANape measurement and
calibration tool from Vector. Other process flows are also explained based on CANape, including
how to create an A2L file and even more. With a cost-free demo version, which is available to you
in the Download Center of the Vector website at www.vector.com/canape_demo, you can see for
yourself.
Introduction
11
12
13
14
Interface 1 of the ASAM interfaces model describes sending and receiving commands and data
between the Slave and the Master. To achieve independence from a specific physical transport
layer, XCP was subdivided into a protocol layer and a transport layer.
CAN
Ethernet
FlexRay
SxI
USB
...
Figure 4: Subdivision of the XCP protocol into protocol layer and transport layer
Depending on the transport layer, one refers to XCP on CAN, XCP on Ethernet, etc. The extendibility to new transport layers was proven as early as 2005 when XCP on FlexRay made its debut.
The current version of the XCP protocol is Version 1.1, which was approved in 2008.
Adherence to the following principles was given high priority in designing the protocol:
> Minimal resource usage in the ECU
> Efficient communication
> Simple Slave implementation
> Plug-and-play configuration with just a small number of parameters
> Scalability
15
A key functionality of XCP is that it enables read and write access to the memory of the Slave.
Read access lets users measure the time response of an internal ECU parameter. ECUs are systems with discrete time behavior, whose parameters only change at specific time intervals: only
when the processor recalculates the value and updates it in RAM. One of the great strengths of
XCP lies in acquiring measured values from RAM which change synchronously to process flows
or events in the ECU. This lets users evaluate direct relationships between time-based process
flows in the ECU and the changing values. These are referred to as event-synchronous measurements. The related mechanisms will be explained later in detail.
Write access lets the user optimize parameters of algorithms in the Slave. The accesses are
address-oriented, i.e. the communication between Master and Slave references addresses in
memory. So, the measurement of a parameter is essentially implemented as a request of the
Master to the Slave: Give me the value of memory location 0x1234. Calibration of a parameter
the write access to the Slave means: Set the value at address 0x9876 to 5.
An XCP Slave does not absolutely need to be used in ECUs. It may be implemented in different environments: from a model-based development environment to hardware-in-the-loop and
software-in-the-loop environments to hardware interfaces that are used to access ECU memory
via debug interfaces such as JTAG, NEXUS and DAP.
Simulink
Slave
Slave
XCP
PC
Master
Slave
Prototype or
ECU Hardware
Measurement/
Calibration
Hardware*
EXE/DLL
Slave
HIL/SIL Systems
Slave
* Debug Interfaces, Memory Emulator, ...
Figure 5:
XCP Slaves can be
used in many
different runtime
environments
16
How can algorithms be optimized using read and write access to the ECU and what benefits
does this offer? To be able to modify individual parameters at runtime in the ECU, there must be
access to them. Not every type of memory permits this process. It is only possible to perform a
read and write access to memory addresses in RAM (intentionally excluding the EEPROM here).
The following is a brief summary of the differences between individual memory technologies:
knowledge of them is very important to understanding over the further course of this book.
Memory Fundamentals
Today, flash memories are usually integrated in the microcontroller chips for ECUs and are used
for long-term storage of code and data, even without power supply. The special aspect of a flash
memory is that read and write access to individual bytes is indeed possible at any time, but writing of new contents can only be done blockwise, usually in rather large blocks.
Flash memories have a limited life, which is specified in terms of a maximum number of erasure
cycles (depending on the specific technology the maximum may be up to one million cycles).
This is also the maximum number of write cycles, because the memory must always be erased as
a block before it can be written again. The reason for this lies in the memory structure: electrons
are pumped via tunnel diodes. A bit is stored at a memory location as follows: electrons must
be transported into the memory location over an electrically insulating layer. Once the electrons are then behind the insulating layer, they form an electric field with their charge, which is
interpreted as a 1 when reading the memory location. If there are no electrons behind the layer,
the cell information is interpreted as a 0. A 1 can indeed be set in this way, but not a 0. Setting
to 0 (=erasing the 1) is performed in a separate erasing routine, in which electrons existing
behind the insulating layer are discharged. However, for architectural reasons, such an erasing
routine does not just act on single bytes, rather only on the group or block level. Depending on
the architecture, blocks of 128 or 256 bytes are usually used. If one wishes to overwrite a byte
within such a block, the entire block must first be erased. Then the entire contents of the block
can be written back.
When this erasing routine is repeated multiple times, the insulating layer (Tunnel Oxide Film)
can be damaged. This means that the electrons could slowly leak away, changing some of the
information from 1 to 0 over the course of time. Therefore, the number of allowable flash cycles
is severely limited in an ECU. In the production ECU, it is often only on the order of single digit
numbers. This restriction is monitored by the Flash Boot Loader, which uses a counter to keep
track of how many flash operations have already been executed. When the specified number is
exceeded, the Flash Boot Loader rejects another flash request.
A RAM (Random Access Memory) requires a permanent power supply; otherwise it loses its contents. While flash memory serves the purpose of long-term storage of the application, the RAM
is used to buffer computed data and other temporary information. Shutting off the power supply causes the RAM contents to be lost. In contrast to flash memory, it is easy to read and write
to RAM.
This fact is clear: if parameters need to be changed at runtime, it must be assured that they are
located in RAM. It is really very important to understand this circumstance. That is why we will
look at the execution of an application in the ECU based on the following example:
In the application, the y parameters are computed from the sensor values x.
// Pseudo-code representation
a = 5;
b = 2;
y = a * x + b;
If the application is flashed in the ECU, the controller handles this code as follows after booting:
the values of the x parameters correspond to a sensor value. At some time point, the application
must therefore poll the sensor value and the value is then stored in a memory location assigned
to the x parameters. Since this value always needs to be rewritten at runtime, the memory location can only lie in RAM.
The parameter y is computed. The values a and b, as factor and offset, are included as information in flash memory. They are stored as constants there. The value of y must also be stored in
RAM, because once again that is the only place where write access is possible. At precisely which
location in RAM the parameters x and y are located, or where a and b lie in flash, is set in the
compiler/linker run. This is where objects are allocated to unique addresses. The relationship
between object name, data type and address is documented in the linker-map file. The linkermap file is generated by the Linker run and can exist in different formats. Common to all formats, however, is that they contain the object name and address at a minimum.
In the example, if the offset b and factor a depend on the specific vehicle, the values of a and b
must be individually adapted to the specific conditions of the vehicle. This means that the algorithm remains as it is, but the parameter values change from vehicle to vehicle.
In the normal operating mode of an ECU, the application runs from the flash memory. It does
not permit any write accesses to individual objects. This means that parameter values which are
located in the flash area cannot be modified at runtime. If a change to parameter values should
be possible during runtime, the parameters to be modified must lie in RAM and not in flash.
Now, how do the parameters and their initial values make their way into RAM? How does one
solve the problem of needing to modify more parameters than can be simultaneously stored in
RAM? These issues lead us to the topic of calibration concepts (see chapter 3).
17
18
19
XCP Header
PID FILL
DAQ
Identification
Field
XCP Tail
TIMESTAMP
DATA
Timestamp
Field
Data
Field
The XCP packet itself is independent of the transport protocol used. It always contains three
components: Identification Field, Timestamp Field and the current data field Data Field.
Each Identification Field begins with the Packet Identifier (PID), which identifies the packet.
The following overview shows which PIDs have been defined:
0xFF
0xFF
0xFE
RES
0xFD
EV
0xFC
SERV
CMD
0xC0
....
0x00
ERR
0xFB
0xBF
absolute or
relative
ODT number
for STIM
....
....
0x00
absolute or
relative
ODT number
for STIM
20
Communication via the XCP packet is subdivided into one area for commands (CTO) and one area
for sending synchronous data (DTO).
XCP Master
XCP Driver
CTO
CMD
RES
DTO
ERR
EV
DAQ
STIM
DAQ
Processor
STIM
Processor
SERV
Bypass
XCP Handler
PGM
CAL
DAQ
Resources
XCP Slave
STIM
Figure 8:
XCP communication
model with CTO/DTO
Command Packet
Command Response Packet
Error
Event Packet
Service Request Packet
Data AcQuisition
Stimulation
sends commands
positive response
negative response
asynchronous event
service request
send periodic measured values
periodic stimulation of the Slave
Commands are exchanged via CTOs (Command Transfer Objects). The Master initiates contact in
this way, for example. The Slave must always respond to a CMD with RES or ERR. The other CTO
messages are sent asynchronously. The Data Transfer Objects (DTO) are used to exchange synchronous measurement and stimulation data.
21
XCP Packet
DAQ
PID FILL
TIMESTAMP
DATA
Figure 9:
Message
identification
Identification Field
When messages are exchanged, both the Master and Slave must be able to determine which
message was sent by the other. This is accomplished in the identification field. That is why each
message begins with the Packet Identifier (PID).
In transmitting CTOs, the PID field is fully sufficient to identify a CMD, RES or other CTO packet.
In Figure 7, it can be seen that commands from the Master to the Slave utilize a PID from 0xC0 to
0xFF. The XCP Slave responds or informs the Master with PIDs from 0xFC to 0xFF. This results in a
unique allocation of the PIDs to the individually sent CTOs.
When DTOs are transmitted, other elements of the identification field are used (see chapter
1.3.4 XCP Packet Addressing for DAQ and STIM).
1.1.2 Time Stamp
XCP Packet
PID FILL
DAQ
TIMESTAMP
DATA
Figure 10:
Time stamp
DTO packets use time stamps, but this is not possible in transmission of a CTO message. The
Slave uses the time stamp to supply time information with measured values. That is, the Master not only has the measured value, but also the time point at which the measured value was
acquired. The amount of time it takes for the measured value to arrive at the Master is no longer important, because the relationship between the measured value and the time point comes
directly from the Slave.
Transmission of a time stamp from the Slave is optional. This topic is discussed further in
ASAM XCP Part 2 Protocol Layer Specification 1.1.0.
22
XCP Packet
PID FILL
DAQ
TIMESTAMP
DATA
Data Field
Figure 11:
Data field
in the XCP packet
Finally, the XCP packet also contains the data stored in the data field. In the case of CTO
packets, the data field consists of specific parameters for the different commands. DTO
packets contain the measured values from the Slave and when STIM data is sent the values from
the Master.
Negative response:
Position Type Description
0
BYTE
Error Packet Code = 0xFE
1
BYTE
Error code
2..MAX_CTO-1 BYTE
Command specific Parameters
Specific parameters can be transmitted as supplemental information with negative responses as
well and not just with positive responses. One example is when the connection is made between
Master and Slave. At the start of a communication between Master and Slave, the Master sends
a connect request to the Slave, which in turn must respond positively to produce a continuous
point-to-point connection.
Master Slave: Connect
Slave Master: Positive response
Connect command:
Position Type Description
0
BYTE
Command Code = 0xFF
1
BYTE Mode
00 = Normal
01 = user defined
Mode 00 means that the Master wishes XCP communication with the Slave. If the Master uses
0xFF 0x01 when making the connection, the Master is requesting XCP communication with the
Slave. Simultaneously, it informs the Slave that it should switch to a specific user-defined
mode.
Positive response of the Slave:
Position Type Description
0
BYTE
Packet ID: 0xFF
1
BYTE RESOURCE
2
BYTE COMM_MODE_BASIC
3
BYTE
MAX_CTO, Maximum CTO size [BYTE]
4
WORD
MAX_DTO, Maximum DTO size [BYTE]
6
BYTE
XCP Protocol Layer Version Number (most significant byte only)
7
BYTE
XCP Transport Layer Version Number (most significant byte only)
The positive response of the Slave can assume a somewhat more extensive form. The Slave
already sends communication-specific information to the Master when making the connection.
RESOURCE, for example, is information that the Slave gives on whether it supports such features
as page switching or whether flashing over XCP is possible. With MAX_DTO, the Slave informs the
Master of the maximum packet length it supports for transfer of the measured values, etc. You
will find details on the parameters in ASAM XCP Part 2 Protocol Layer Specification 1.1.0
23
24
XCP permits three different modes for exchanging commands and reactions between Master and
Slave: Standard, Block and Interleaved mode.
Standard Mode
Master
Block Mode
Interleaved Mode
Slave Master
Slave
Master
Request k
Part1
Request k
Part2
Part3
Slave
Request k
MIN_ST
Request k+1
MAX_BS
Response k
Response k
Response k
Request k+1
Request k+1
Response k+1
Response k+1
Part1
Response k+1
Part2
Part3
Time
Time
Time
Figure 12: The three modes of the XCP protocol: Standard, Block and Interleaved mode
In the standard communication model, each request to a Slave is followed by a single response.
Except with XCP on CAN, it is not permitted for multiple Slaves to react to a command from the
Master. Therefore, each XCP message can always be traced back to a unique Slave. This mode is
the standard case in communication.
The block transfer mode is optional and saves time in large data transfers (e.g. upload or
download operations). Nonetheless, performance issues must be considered in this mode
in the direction of the Slave. Therefore, minimum times between two commands (MIN_ST)
must be maintained and the total number of commands must be limited to an upper limit
MAX_BS. Optionally, the Master can read out these communication settings from the Slave with
GET_COMM_MODE_INFO. The aforementioned limitations do not need to be observed in block
transfer mode in the direction of the Master, because performance of the PC nearly always suffices to accept the data from a microcontroller.
The interleaved mode is also provided for performance reasons. But this method is also optional
and in contrast to block transfer mode it has no relevance in practice.
25
1.2.2 CMD
DATA
Data Field
The Master sends a general request to the Slave over CMD. The PID (Packet Identifier) field
contains the identification number of the command. The additional specific parameters are
transported in the data field. Then the Master waits for a reaction of the Slave in the form of a
RESponse or an ERRor.
XCP is also very scalable in its implementation, so it is not necessary to implement every command. In the A2L file, the available CMDs are listed in what is known as the XCP IF_DATA. If there
is a discrepancy between the definition in the A2L file and the implementation in the Slave, the
Master can determine, based on the Slaves reaction, that the Slave does not even support the
command. If the Master sends a command that is not implemented in the Slave, the Slave must
acknowledge with ERR_CMD_UNKNOWN and no further activities are initiated in the Slave. This
lets the Master know quickly that an optional command has not been implemented in the Slave.
Some other parameters are included in the commands as well. Please take the precise details
from the protocol layer specification: ASAM XCP Part 2 Protocol Layer Specification 1.1.0.
The commands are organized in groups: Standard, Calibration, Page, Programming and DAQ
measurement commands. If a group is not needed at all, its commands do not need to be implemented. If the group is necessary, certain commands must always be available in the Slave,
while others from the group are optional.
The following overview serves as an example. The SET_CAL_PAGE and GET_CAL_PAGE commands
in the Page-Switching group are identified as not optional. This means that in an XCP Slave that
supports Page Switching at least these two commands must be implemented. If Page-Switching
support is unnecessary in the Slave, these commands do not need to be implemented. The same
applies to other commands.
26
Standard commands:
Command PID Optional
CONNECT 0xFF No
DISCONNECT 0xFE No
GET_STATUS 0xFD No
SYNCH
0xFC No
GET_COMM_MODE_INFO 0xFB
Yes
GET_ID
0xFA Yes
SET_REQUEST 0xF9 Yes
GET_SEED 0xF8 Yes
UNLOCK
0xF7 Yes
SET_MTA 0xF6 Yes
UPLOAD
0xF5 Yes
SHORT_UPLOAD 0xF4
Yes
BUILD_CHECKSUM 0xF3
Yes
TRANSPORT_LAYER_CMD 0xF2
Yes
USER_CMD 0xF1 Yes
Calibration commands:
Command PID Optional
DOWNLOAD 0xF0 No
DOWNLOAD_NEXT 0xEF
Yes
DOWNLOAD_MAX 0xEE
Yes
SHORT_DOWNLOAD 0xED
Yes
MODIFY_BITS 0xEC Yes
Standard commands:
Command PID Optional
SET_CAL_PAGE 0xEB No
GET_CAL_PAGE 0xEA No
GET_PAG_PROCESSOR_INFO 0xE9
Yes
GET_SEGMENT_INFO 0xE8
Yes
GET_PAGE_INFO 0xE7
Yes
SET_SEGMENT_MODE 0xE6
Yes
GET_SEGMENT_MODE 0xE5
Yes
COPY_CAL_PAGE 0xE4
Yes
27
28
Flash programming:
Command PID Optional
PROGRAM_START 0xD2
No
PROGRAM_CLEAR 0xD1
No
PROGRAM 0xD0 No
PROGRAM_RESET 0xCF
No
GET_PGM_PROCESSOR_INFO 0xCE
Yes
GET_SECTOR_INFO 0xCD
Yes
PROGRAM_PREPARE 0xCC
Yes
PROGRAM_FORMAT 0xCB
Yes
PROGRAM_NEXT 0xCA Yes
PROGRAM_MAX 0xC9 Yes
PROGRAM_VERIFY 0xC8
Yes
1.2.3 RES
If the Slave is able to successfully comply with a Masters request, it gives a positive acknowledge with RES.
Position
0
1..MAX_CTO-1
Type Description
BYTE
Packet Identifier = RES 0xFF
BYTE
Command response data
You will find more detailed information on the parameters in ASAM XCP Part 2 Protocol Layer
Specification 1.1.0.
1.2.4 ERR
If the request from the Master is unusable, it responds with the error message ERR and an error
code.
Position
0
1
2..MAX_CTO-1
Type Description
BYTE
Packet Identifier = ERR 0xFE
BYTE
Error code
BYTE
Optional error information data
You will find a list of possible error codes in ASAM XCP Part 2 Protocol Layer Specification 1.1.0.
29
1.2.5 EV
If the Slave wishes to inform the Master of an asynchronous event, an EV can be sent to do this.
Its implementation is optional.
Position
0
1
2..MAX_CTO-1
Type Description
BYTE
Packet Identifier = EV 0xFD
BYTE
Event code
BYTE
Optional event information data
You will find more detailed information on the parameters in ASAM XCP Part 2 Protocol Layer
Specification 1.1.0.
Events will be discussed much more in relation to measurements and stimulation. This has nothing to do with the action of the XCP Slave that initiates sending of an EVENT. Rather it involves
the Slave reporting a disturbance such as the failure of a specific functionality.
1.2.6 SERV
The Slave can use this mechanism to request that the Master execute a service.
Position
0
1
2..MAX_CTO-1
Type Description
BYTE
Packet Identifier = SERV 0xFC
BYTE
Service request code
BYTE
Optional service request data
You will find the Service Request Code table in ASAM XCP Part 2 Protocol Layer Specification 1.1.0.
1.2.7 Calibrating Parameters in the Slave
To change a parameter in an XCP Slave, the XCP Master must send the parameters location as
well as the value itself to the Slave.
XCP always defines addresses with five bytes: four for the actual address and one byte for the
address extension. Based on a CAN transmission, only seven useful bytes are available for XCP
messages. For example, if the calibrator sets a 4-byte value and wants to send both pieces of
information in one CAN message, there is insufficient space to do this. Since a total of nine
bytes are needed to transmit the address and the new value, the change cannot be transmitted in one CAN message (seven useful bytes). The calibration request is therefore made with
two messages from Master to Slave. The Slave must acknowledge both messages and in sum four
messages are exchanged.
30
The following figure shows the communication between Master and Slave, which is necessary to
set a parameter value. The actual message is located in the line with the envelope symbol. The
interpretation of the message is shown by expanding it with the mouse.
In the first message of the Master (highlighted in gray in Figure 14), the Master sends the
command SET_MTA to the Slave with the address to which a new value should be written. In
the second message, the Slave gives a positive acknowledge to the command with Ok:SET_MTA.
The third message DOWNLOAD transmits the hex value as well as the valid number of bytes.
In this example, the valid number of bytes is four, because it is a float value. The Slave gives
another positive acknowledge in the fourth message.
This completes the current calibration process. In the Trace display, you can recognize a terminating SHORT_UPLOAD a special aspect of CANape, the measurement and calibration tool from
Vector. To make sure that the calibration was performed successfully, the value is read out again
after the process and the display is updated with the read-out value. This lets the user directly
recognize whether the calibration command was implemented. This command also gets a positive acknowledge with Ok:SHORT_UPLOAD.
When the parameter changes in the ECUs RAM, the application processes the new value. A
reboot of the ECU, however, would lead to erasure of the value and overwriting of the value in
RAM with the original value from the flash (see chapter 3 Calibration Concepts). So, how can
the modified parameter set be permanently saved?
31
32
In the flash file, there is a hex file that contains both the addresses and the values. Now a
parameter file can be copied to a hex file. To do this, CANape takes the address and the value
from the parameter set file and updates the parameter value at the relevant location in the
hex file. This results in a new hex file, which contains the changed parameter values. However,
this Hex file must now possibly run through further process steps to obtain a flashable file.
One recurring problem here is the checksums, which the ECU checks to determine whether it
received the data correctly. If the flashable file exists, it can be flashed in the ECU and after the
reboot the new parameter values are available in the ECU.
33
The Master sends data to the Slave by STIM. This communication also consists of two phases:
In the initialization phase, the Master communicates to the Slave which data it will send to the
Slave. After this phase, the Master sends the data to the Slave and the STIM processor saves the
data. As soon as a related STIM event is triggered in the Slave, the data is transferred to the
application memory.
1.3.1 Measurement Methods: Polling versus DAQ
Before explaining how event-synchronous, correlated data is measured from a Slave, here is a
brief description of another measurement method known as Polling. It is not based on DTOs, but
on CTOs instead. Actually, this topic should be explained in a separate chapter, but a description
of polling lets us derive, in a very elegant way, the necessity of DTO-based measurement, so a
minor side discussion at this point makes sense.
The Master can use the SHORT_UPLOAD command to request the value of a measurement para
meter from the Slave. This is referred to as polling. This is the simplest case of a measure
ment: sending the measured value of a measurement parameter at the time at which the
SHORT_UPLOAD command has been received and executed.
In the following example, the measurement parameter Triangle is measured from the Slave:
Figure 17:
Address information
of the parameter
Triangle from the
A2L file
The address 0x60483 is expressed as an address with five bytes in the CAN frame: one byte for
the address extension and four bytes for the actual address.
34
The XCP specification sets a requirement for polling: that the value of each measurement parameter must be polled individually. For each value to be measured via polling, two messages must
go over the bus: the Masters request to the Slave and the Slaves response to the Master.
Besides this additional bus load, there is another disadvantage of the polling method: When
polling multiple data values, the user normally wants the data to correlate to one another. However, multiple values that are measured sequentially with polling do not necessarily stand in
correlation to one another, i.e. they might not originate from the same ECU computing cycle.
This limits the suitability of polling for measurement, because it produces unnecessarily high
data traffic and the measured values are not evaluated in relation to the process flows in the
ECU.
So, an optimized measurement must solve two tasks:
> Bandwidth optimization during the measurement
> Assurance of data correlation
This task is handled by the already mentioned DAQ method. DAQ stands for Data Acquisition and
it is implemented by sending DTOs (Data Transfer Objects) from the Slave to the Master.
1.3.2 DAQ Measurement Method
The DAQ method solves the two problems of polling as follows:
> The correlation of measured values is achieved by coupling the acquisition of measured values to the events in the ECU. The measured values are not acquired and transferred until it has
been assured that all computations have been completed.
> To reduce bus load, the measurement process is subdivided into two phases: In a configu
ration phase, the Master communicates which values it is interested in to the Slave and the
second phase just involves transferring the measured values of the Slave to the Master.
35
How can the acquisition of measured values now be coupled to processes in the ECU? Figure 19
shows the relationship between calculation cycles in the ECU and the changes in parameters X
and Y.
Calculation
cycle n
10
8
6
4
2
0
10
8
6
4
2
0
Calculation
cycle n+1
E1
Read sensor X
E1
Calculate Y = X
Calculation
cycle n+2
time
E1
Figure 19:
Events in the ECU
Lets have a look at the sequence in the ECU: When event E1 (= end of computation cycle) is
reached, then all parameters have been acquired and calculations have been made. This means
that all values must match one another and correlate at this time point. This means that we
use an event-synchronous measurement method. This is precisely what is implemented with the
help of the DAQ mechanism: When the algorithm in the Slave reaches the Computational cycle
completed event, the XCP Slave collects the values of the measurement parameters, saves them
in a buffer and sends them to the Master. This assumes that the Slave knows which parameters
should be measured for which event.
An event does not absolutely have to be a cyclic, time-equidistant event, rather in the case of
an engine controller, for example, it might be angle-synchronous. This makes the time interval between two events dependent on the engine rpm. A singular event, such as activation of a
switch by the driver, is also an event that is not by any means equidistant in time.
The user selects the signals. Besides the actual measurement object, the user must select the
underlying event for the measurement parameters. The events as well as the possible assignments of the measurement objects to the events must be stored in the A2L file.
Figure 20:
Event definition
in an A2L
36
In the normal case, it does not make any sense to be able to simultaneously assign a measured
value to multiple events. Generally, a parameter is only modified within a single cycle (e.g. only
at 10-ms intervals) and not in multiple cycles (e.g. at 10-ms and 100-ms intervals).
Figure 21:
Allocation of
Triangle to possible
events in the A2L
Figure 21 shows that the Triangle parameter can in principle be measured with the 1 ms,
10 ms and 100 ms events. The default setting is 10 ms.
Measurement parameters are allocated to events in the ECU during measurement configuration
by the user.
After configuring the measured signals, the user starts the measurement. The XCP Master lists
the desired measurement parameters in what are known as DAQ lists. In these lists, the measured signals are each allocated to selected events. This configuration information is sent to the
Slave before the actual start of measurement. Then the Slave knows which addresses it should
read out and transmit when an event occurs. This distribution of the measurement into a configuration phase and a measurement phase was already mentioned at the very beginning of this
chapter.
This solves both problems that occur in polling: bandwidth is used optimally, because the Master no longer needs to poll each value individually during the measurement and the measured
values correlate with one another.
Figure 23: Excerpt from the CANape Trace window of a DAQ measurement
37
38
RAM Cells
ODT
address, length
address, length
address, length
address, length
...
0
1
2
3
PID
...
Figure 24:
ODT: Allocation
of RAM addresses
to DAQ DTO
Stated more precisely, an entry in an ODT list references a memory area in RAM by the address
and length of the object.
After receiving the measurement start command, at some point an event occurs that is associated with a measurement. The XCP Slave begins to acquire the data. It combines the individual objects into packets and sends them on the bus. The Master reads the bus message and
can interpret the individual data, because it has defined the allocation of individual objects to
packets itself and therefore it knows their relationships.
However, each packet has a maximum number of useful bytes, which depends on the transport medium that is used. In the case of CAN, this amounts to seven bytes. If more data needs
to be measured, an ODT is no longer sufficient. If two or more ODTs need to be used to transmit the measured values, then the Slave must be able to copy the data into the correct ODT and
the Master must be able to uniquely identify the received ODTs. If multiple measurement intervals of the ECU are used, the relationship between ODT and measurement interval must also be
uniquely identifiable.
39
The ODTs are combined into DAQ lists in the XCP protocol. Each DAQ list contains a number of
ODTs and is assigned to an event.
1 address, length
0 address, length
2 address, length
1 address, length
address, length
3 address,
2 address,
lengthlength
address, length
...
3 address, length
address, length
...
address, length
...
PID=2 0
PID=1 0
PID=0 0
1
2
1
2
2
3
...
...
...
Figure 25:
DAQ list
with three ODTs
For example, if the user uses two measurement intervals (= two different events in the ECU),
then two DAQ lists are used as well. One DAQ list is needed per event used. Each DAQ list contains
the entries related to the ODTs and each ODT contains references to the values in the RAM cells.
DAQ lists are subdivided into the types: static, predefined and dynamic.
Static DAQ lists:
If the DAQ lists and ODT tables are permanently defined in the ECU, as is familiar from CCP, they
are referred to as static DAQ lists. There is no definition of which measurement parameters exist
in the ODT lists, rather only the framework that can be filled (in contrast to this, see predefined
DAQ lists).
In static DAQ lists, the definitions are set in the ECU code and are described in the A2L. Figure
26 shows an excerpt of an A2L, in which static DAQ lists are defined:
Figure 26:
Static DAQ lists
In the above example, there is a DAQ list with the number 0, which is allocated to a 10-ms event
and can carry a maximum of two ODTs. The DAQ list with the number 1 has four ODTs and is linked
to the 100 ms event.
40
The A2L matches the contents of the ECU. In the case of static DAQ lists, the number of DAQ lists
and the ODT lists they each contain are defined with the download of the application into the
ECU. If the user now attempts to measure more signals with an event than fit in the allocated
DAQ list, the Slave in the ECU will not be able to fulfill the requirements and the configuration
attempt is terminated with an error. It does not matter that the other DAQ list is still fully available and therefore actually still has transmission capacity.
Predefined DAQ lists:
Entirely predefined DAQ lists can also be set up in the ECU. However, this method is practically
never used in ECUs due to the lack of flexibility for the user. It is different for analog measurement systems which transmit their data by XCP: Flexibility is unnecessary here, since the physical structure of the measurement system remains the same over its life.
Dynamic DAQ lists:
A special aspect of the XCP protocol are the dynamic DAQ lists. It is not the absolute parameters
of the DAQ and ODT lists that are permanently defined in the ECU code here, but just the parameters of the memory area that can be used for the DAQ lists. The advantage is that the measurement tool has more latitude in putting together the DAQ lists and it can manage the structure
of the DAQ lists dynamically.
Various functions especially designed for this dynamic management are available in XCP such as
ALLOC_ODT which the Master can use to define the structure of a DAQ list in the Slave.
MIN_DAQ + DAQ_COUNT
DAQ1
DAQ0
AQ
_D
OC
ALL
ALLOC_OD
T_ENTRY
ALLOC_ODT
ODT_ENTERIES_COUNT
GRANULARITY_ODT_ENTRY_SIZE_DAQ
ODT_COUNT
Figure 27:
Dynamic DAQ lists
In putting together the DAQ lists, the Master must be able to distinguish whether dynamic or
static DAQ lists are being used, how the parameters and structures of the DAQ lists look, etc.
If the Master sends data to the Slave by STIM, the XCP Slave must be informed of the location in
the packets at which the calibration parameters can be found. The same mechanisms are used
here as are used for the DAQ lists.
41
42
Timestamp Field
Data Field
PID
PID DAQ
PID
TS
DAQ
PID FILL
TS
DAQ
TIMESTAMP
DATA
Figure 29:
Structure of the
XCP packet for DTO
transmissions
43
Identification Field
PID
absolute ODT number
Figure 30:
Identification field
with absolute
ODT numbers
Transmission type: relative ODT numbers and absolute DAQ lists numbers
In this case, both the DAQ lists number and the ODT number can be transmitted in the Identification Field. However, there is still space left over in the number of bytes that is available for
the information:
Identification Field
PID DAQ
absolute DAQ List number
relative ODT number
Figure 31:
ID field with
relative ODT and
absolute DAQ
numbers (one byte)
In the figure, one byte is available for the DAQ number and one byte for the ODT number.
The maximum number of DAQ lists can be transmitted using two bytes:
Identification Field
PID
DAQ
Figure 32:
ID field with
relative ODT and
absolute DAQ
numbers (two bytes)
44
If it is not possible to send three bytes, it is also possible to work with four bytes by using a fill
byte:
Identification Field
PID FILL
DAQ
Figure 33:
ID field with relative
ODT and absolute DAQ
numbers as well as fill
byte (total of four bytes)
How does the XCP Master now learn which method the Slave is using? First, by the entry in the
A2L and second by the request to the Slave to determine which communication version it has
implemented.
The response to the GET_DAQ_PROCESSOR_INFO request also sets the DAQ_KEY_BYTE that the
Slave uses to inform the Master which transmission type is being used. If not only DAQ is being
used, but also STIM, the Master must use the same method for STIM that the Slave uses for DAQ.
1.3.5 Bypassing = DAQ + STIM
Bypassing can be implemented by joint use of DAQ and STIM (see Figure 8) and it represents
a special form of a rapid prototyping solution. For a deeper understanding, however, further
details are necessary, so this method is not explained until chapter 4.5 Bypassing.
45
Data
Frame
CAN
Node A
CAN
Node B
ID=0x12
Sender
Receiver
ID=0x34
Sender
ID=0x52
Receiver
ID=0x67
Receiver
ID=0xB4
Receiver
ID=0x3A5
Sender
Receiver
CAN
Node C
CAN
Node D
Receiver
Receiver
Sender
Sender
Receiver
Sender
Receiver
Receiver
Receiver
Figure 34:
Definition of which
bus nodes send
which messages
The message with ID 0x12 is sent by CAN node A and all other nodes on the bus receive this message. In the framework of acceptance testing, CAN nodes C and D conclude that they do not
need the message and they reject it. CAN node B, on the other hand, determines that its higherlevel layers need the message and they provide them via the Rx buffer. The CAN nodes are interlinked as follows:
46
CAN Node A
CAN Node B
Host
Host
CAN Interface
CAN Interface
Tx
Buffer
Rx
Buffer
Tx
Buffer
Rx
Buffer
Acceptance
Test
Acceptance
Test
Receive
Send
Receive
Send
CAN
Send
Receive
Send
Receive
Acceptance
Test
Acceptance
Test
Rx
Tx
Buffer
Buffer
CAN Interface
Rx
Tx
Buffer
Buffer
CAN Interface
Host
Host
CAN Node C
CAN Node D
Figure 35:
Representation
of a CAN network
The XCP messages are not described in the communication matrix! If measured values are sent
from the Slave via dynamic DAQ lists, e.g. with the help of XCP, the messages are assembled
according to the signals selected by the user. If the signal selection changes, the message contents change as well. Nonetheless, there is a relationship between the communication matrix
and XCP: CAN identifiers are needed to transmit the XCP messages over CAN. To minimize the
number of CAN identifiers used, the XCP communication is limited to the use of just two CAN
identifiers that are not being used in the DBC for normal communication. One identifier is
needed to send information from the Master to the Slave; the other is used by the Slave for the
response to the Master.
The excerpt from the CANape Trace window shows the CAN identifiers that are used under the
ID column. In this example, just two different identifiers are used: 554 as the ID for the message from Master to Slave (direction Tx) and 555 for sending messages from the Slave to the
Master (direction Rx).
47
In this example, the entire XCP communication is handled by the two CAN identifiers 554 and
555. These two IDs may not be allocated for other purposes in this network.
The CAN bus transmits a maximum of eight useful bytes per message. In the case of XCP, however, we need information on the command used or the sent response. This is provided in the
first byte of the CAN useful data. This means that seven bytes are available per CAN message for
transporting useful data.
XCP Packet
TIMESTAMP
Control Field
empty for CAN
XCP Tail
DATA
Fill
Control Field
for CAN
In CANape, you will find an XCP-on-CAN demo with the virtual ECU XCPsim. You can learn about
more details of the standard in ASAM XCP on CAN Part 3 Transport Layer Specification 1.1.0.
48
1.4.2 FlexRay
A basic idea in the development of FlexRay was to implement a redundant system with deterministic time behavior. The connection redundancy was achieved by using two channels: channel A and channel B. If multiple FlexRay nodes (= ECUs) are redundantly interconnected and
one branch fails, the nodes can switch over to the other channel to make use of the connection
redundancy.
Node K
Node L
Node M
Node N
Node O
CH A
CH B
Deterministic behavior is achieved by transmitting data within defined time slots. Also defined
here is which node sends which content in which time slot. These time slots are combined to
form one cycle. The cycles repeat here, as long as the bus is active. The assembly of the time
slots and their transport contents (who sends what at which time) is known as Scheduling.
Node K
Slot
1
3
Node L
Direction Frame
a
Tx
Rx
x
Frame: a
Frame: b
Slot 1
t1
Slot
1
3
Direction Frame
Tx
a
Rx
b
Frame: x
Slot 2
t2
Node M
Frame: a
Slot 3
t3
Slot
1
3
Frame: b
Slot 1
t4
Communication Cycle
Direction Frame
Tx
a
Rx
x
Frame: x
Slot 2
t5
...
t6
Real-time
49
In the first communication cycle, node K sends frame a in slot 1. The scheduling is also stored in
the software of nodes L and M. Therefore, the contents of frame a are passed to the next higher
communication levels.
Static Segment
Scheduling is consolidated in a description file. This is not a DBC file, as in the case of CAN,
rather it is a FIBEX file. FIBEX stands for Field Bus Exchange Format and could also be used
for other bus systems. However, its current use is practically restricted to the description of the
FlexRay bus. FIBEX is an XML format and the XCP-on-FlexRay specification relates to FIBEX Version 1.1.5 and FlexRay specification Version 2.1.
Slot
ECU
Node K
Node M
Node L
Dynamic Segment
5
6
Channel
Cycles
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
b [rep : 1 ]
...
b [rep : 1 ]
63
c [rep : 4 ]
x [rep : 2 ]
y [rep : 4 ]
x [rep : 2 ]
c [repc : 4 ]
x [rep : 2 ]
y [rep : 4 ]
x [rep : 2 ]
B
A
a [rep : 1 ]
a [rep : 1 ]
a [rep : 1 ]
a [rep : 1 ]
a [rep : 1 ]
a [rep : 1 ]
a [rep : 1 ]
a [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
d [rep : 1 ]
Node L
n [rep : 1 ]
n [rep : 1 ]
n [rep : 1 ]
n [rep : 1 ]
n [rep : 1 ]
n [rep : 1 ]
n [rep : 1 ]
n [rep : 1 ]
Node O
m [rep : 1 ]
m [rep : 1 ]
m [rep : 1 ]
m [rep : 1 ]
m [rep : 1 ]
m [rep : 1 ]
m [rep : 1 ]
m [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
r [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
o [rep : 1 ]
t [rep : 2 ]
p [rep : 4 ]
t [rep : 2 ]
t [rep : 2 ]
p [rep : 4 ]
t [rep : 2 ]
Node N
B
A
Node K
Node M
A
B
Node L
Node L
Node O
u [rep : 4 ]
u [rep : 4 ]
v [rep : 8 ]
A
w [rep : 4 ]
w [rep : 4 ]
Another format for describing bus communication has been defined as a result of the development of AUTOSAR solutions: the AUTOSAR Description File, which is available in XML format. The
definition of XCP-on-FlexRay was taken into account in the AUTOSAR 4.0 specification. However,
at the time of publication of this book this specification has not yet been officially approved and
therefore it will not be discussed further.
Due to other properties of the FlexRay bus, it is not sufficient to just give the slot number as
a reference to the contents. One reason is that multiplexing is supported: whenever a cycle is
repeated, the transmitted contents are not necessarily the same. Multiplexing might specify
that a certain piece of information is only sent in the slot in every second pass.
50
Instead of indicating the pure slot number, FlexRay Data Link Layer Protocol Data Unit Identifiers (FLX_LPDU_ID) are used, which can be understood as a type of generalized Slot ID. Four
pieces of information are needed to describe such an LPDU:
> FlexRay Slot Identifier (FLX_SLOT_ID)
> Cycle Counter Offset (OFFSET)
> Cycle Counter Repetition (CYCLE_REPETITION)
> FlexRay Channel (FLX_CHANNEL)
Cycle ID
LPDU_ID
..
.
.. .. ..
. . .
.. .. ..
. . .
..
.
.. .. .. ..
. . . .
.. .. ..
. . .
...
Channel A
... ...
Channel B
..... .. .. .. ..
.. .. ..
. . . . .
. . .
.. .. .. .. ..
.. .. .. ..
. . . . .
.
. . . ...
... ...
... ...
...
Slot ID
Figure 41:
Representation of
the FlexRay LPDUs
Scheduling also has effects on the use of XCP on FlexRay, because it defines what is sent precisely. This cannot be readily defined in XCP; not until the measurement runtime does the user
define which measured values are sent by assembling signals. This means that it is only possible
to choose which aspect of XCP communication can be used in which LPDU: CTO or DTO from Master to Slave or from Slave to Master.
The following example illustrates this process: the XCP Master may send a command (CMD) in
slot n and Slave A gives the response (RES) in slot n+2. XCP-on-FlexRay messages are always
defined using LPDUs.
The A2L description file is needed for access to internal ECU parameters; the objects with their
addresses in the ECU are defined in this file. In addition, the FIBEX file is necessary, so that
the XCP Master knows which LPDUs it may send and to which LPDUs the XCP Slaves send their
responses. Communication between XCP Master and XCP Slave(s) can only function through
combination of the two files, i.e. by having an A2L file reference a FIBEX file.
51
Cycle ID
XCP-dedicated LPDU_IDs
..
.
.. .. ..
. . .
.. .. ..
. . .
..
.
.. .. .. ..
. . . .
.. .. ..
. . .
...
Channel A
... ...
Channel B
..... .. .. .. ..
.. .. ..
. . . . .
. . .
.. .. .. .. ..
.. .. .. ..
. . . . .
.
. . . ...
... ...
... ...
...
Slot ID
Figure 42:
Allocation of
XCP communication
to LPDUs
You can read more details about XCP on FlexRay in CANapes online Help. Supplied with CANape
is the FIBEX Viewer, which lets users conveniently view the scheduling. It is easy to allocate the
XCP messages to the LPDUs by making driver settings for the XCP-on-FlexRay device in CANape.
The protocol is explained in detail in ASAM XCP on FlexRay Part 3 Transport Layer Specification
1.1.0. You will find an XCP-on-FlexRay demo in CANape with the virtual ECU XCPsim. The demo
requires real Vector FlexRay hardware.
1.4.3 Ethernet
XCP on Ethernet can be used with either TCP/IP or UDP/IP. TCP is a protected transport protocol
on Ethernet, in which the handshake method is used to detect any loss of a packet. In case of
packet loss, TCP organizes a repetition of the packet. UDP does not offer this protection mechanism. If a packet is lost, UDP does not offer any mechanisms for repeated sending of the lost
packet on the protocol level.
Not only can XCP on Ethernet be used with real ECUs, it can also be used for measurement and
calibration of virtual ECUs. Here, a virtual ECU is understood as the use of code that would other
wise run in the ECU as an executable program (e.g. DLL) on the PC. Entirely different resources
are available here compared to an ECU (CPU, memory, etc.).
52
But first the actual protocol will be discussed. IP packets always contain the addresses of the
sender and receiver. The simplest way to visualize an IP packet is as a type of letter that contains
the addresses of the recipient and the sender. The addresses of individual nodes must always be
unique. A unique address comprises the IP address and port number.
CTR
XCP Packet
PID FILL
Control Field
for Ethernet
(TCP/ IP and UDP/IP)
DAQ
TIMESTAMP
Length (LEN)
DATA
XCP Tail
empty for Ethernet
(TCP/IP and UDP/IP)
Control Field
empty for Ethernet
(TCP&IP and UDP&IP)
The header consists of a Control Field with two words in Intel format (= four bytes). These words
contain the length (LEN) and a counter (CTR). LEN indicates the number of bytes in the XCP
packet. The CTR is used to detect the packet loss. UDP/IP is not a protected protocol. If a packet
is lost, this is not recognized by the protocol layer. Packet loss is monitored by counter information. When the Master sends its first message to the Slave, it generates a counter number
that is incremented with each additional transmission of a frame. The Slave responds with the
same pattern: It increments its own counter with each frame that it sends. The counters of the
Slave and the Master operate independently of one another. UDP/IP is well suited for sending
measured values. If a packet is lost, then the measured values it contains are lost, resulting in
a measurement gap. If this occurs infrequently, the loss might just be ignored. But if the measured data is to be used as the basis for fast control, it might be advisable to use TCP/IP.
An Ethernet packet can transport multiple XCP packets, but an XCP packet may never exceed the
limits of a UDP/IP packet. In the case of XCP on Ethernet, there is no Tail, i.e. an empty control field.
You will find more detailed information on the protocol in ASAM XCP on Ethernet Part 3 Transport Layer Specification 1.1.0. In CANape, you will also find an XCP on Ethernet demo with the
virtual ECU XCPsim or with virtual ECUs in the form of DLLs, which have been implemented by
Simulink models and the Simulink Coder.
53
1.4.4 SxI
SxI is a collective term for SPI or SCI. Since they are not buses, but instead are controller interfaces which are only suited for point-to-point connections, there is no addressing in this type
of transmission. The communication between any two nodes runs either synchronously or
asynchronously.
CTR
XCP Packet
PID FILL
Control Field
for SxI
DAQ
TIMESTAMP
Length (LEN)
XCP Tail
DATA
FILL
CS
Control Field
for SxI
Checksum (CS)
Figure 44: XCP-on-SxI packet
The XCP header consists of a control field with two pieces of information: the length LEN and
the counter. The length of these parameters may be in bytes or words (Intel format). LEN indicates the number of bytes of the XCP packet. The CTR is used to detect the loss of a packet. This
is monitored in the same way as for XCP on Ethernet: with counter information. Under certain
circumstances it may be necessary to add fill bytes to the packet, e.g. if SPI is used in WORD or
DWORD mode or to avoid the message being shorter than the minimal packet length. These fill
bytes are appended in the control field.
You will find more detailed information on the protocol in ASAM XCP on SxI Part 3 Transport
Layer Specification 1.1.0.
1.4.5 USB
Currently, XCP on USB has no practical significance. Therefore, no further mention will be made
of this topic; rather we refer you to ASAM documents that describe the standard: ASAM XCP on
USB Part 3 Transport Layer Specification 1.1.0.
1.4.6 LIN
At this time, ASAM has not yet defined an XCP-on-LIN standard. However, a solution exists from
Vector (XCP-on-LIN driver and CANape as XCP-on-LIN Master), which violates neither the LIN nor
the XCP specification and is already being used on some customer projects. For more detailed
information, please contact Vector.
54
Segment 1
Page 0
Segmemt 1
Sector 2
XCP access
Segment 1
Page 1
Segment 1
Page 2
Sector 0
Segment 0
Page 0
Segmemt 0
Sector 1
ECU access
address
Figure 45:
Memory
representation
From an XCP perspective, the memory of a Slave consists of a continuous memory that is
addressed with a 40-bit width. The physical layout of the memory is based on sectors. Know
ledge of the flash sectors is absolutely necessary in flashing, because the flash memory can only
be erased a block at a time.
The logical structure is based on what are known as segments; they describe where calibration
data is located in memory. The start address and parameters of a segment do not have to be
aligned with the start addresses and parameters of the physical sectors. Each segment can be
subdivided into multiple pages. The pages of a segment describe the same parameters at the
same addresses. The values of these parameters and read/write rights can be controlled individually for each page.
The allocation of an algorithm to a page within a segment must always be unique. Only one page
may be active in a segment at any given time. This page is known as the active page for the
ECU in this segment. The particular page that the ECU and the XCP driver actively access can be
individually switched. No interdependency exists between these settings. Similar to the naming convention for the ECU, the active page for XCP access is referred to as the active page for
XCP access in this segment.
In turn, this applies to each individual segment. Segments must be listed in the A2L file and
each segment gets a number that is used to reference the segment. Within an XCP Slave, the
SEGMENT_NUMBER must always begin at 0 and it is then incremented in consecutive numbers.
Each segment has at least one page. The pages are also referenced by numbers. The first page
is PAGE 0. One byte is available for the number, so that a maximum of 255 pages can be defined
per segment.
The Slave must initialize all pages for all segments. The master uses the command GET_CAL_PAGE
to ask the Slave which page is currently active for the ECU and which page for XCP access. It
can certainly be the case that mutual blocking may be necessary for the accesses. For example, the XCP Slave may not access a page, if this page is currently active for the ECU. As mentioned, there may be a dependency but not necessarily. It is a question of how the Slave has
been implemented.
If the Slave supports the optional commands GET_CAL_PAGE and SET_CAL_PAGE, then it also
supports what is known as page swapping. These two commands let the Master poll which pages
are currently being used and if necessary it can swap pages for the ECU and XCP access. The XCP
Master has full control over swapping of pages. The XCP Slave cannot initiate swapping by itself.
But naturally the Master must respect any restrictions of the Slave implementation.
What is the benefit of swapping?
First, swapping permits very quick changing of entire parameter sets essentially a before-andafter comparison. Second, the plant remains in a stable state, while the calibrator performs
extensive parameter changes on another page in the ECU. This prevents the plant from going
into a critical or unstable state, e.g. due to incomplete datasets during parameter setting.
55
56
Figure 46:
Representation
of driver settings
for the flash area
Flashing can be implemented using what are referred to as flash kernels. A flash kernel is executable code that is sent to the Slaves RAM area before the actual flashing; the kernel then handles communication with the XCP Master. It might contain the algorithm that is responsible for
erasing the flash memory. For security and space reasons, very frequently this code is not permanently stored in the ECUs flash memory. Under some circumstances, a converter might be
used, e.g. if checksum or similar computations need to be performed.
Flashing with XCP roughly subdivides the overall flash process into three areas:
> Preparation (e.g. for version control and therefore to check whether the new contents
can even be flashed)
> Execution (the new contents are sent to the ECU)
> Post-processing (e.g. checksum checking etc.)
In the XCP standard, the primary focus is directed to the actual execution of flashing. Anyone who compares this operation to flashing over diagnostic protocols will discover that the
process-specific elements, such as serial number handling with meta-data, are supported in
a rather spartan fashion in XCP. Flashing in the development phase was clearly the main focus
in its definition and not the complex process steps that are necessary in end-of-line flashing.
Therefore, what is important in the preparation phase is to determine whether the new contents are even relevant to the ECU. There are no special commands for version control. Rather
the practice has been to support those commands specific to the project.
The following XCP commands are available:
PROGRAM_START: Beginning of the flash procedure
This command indicates the beginning of the flash process. If the ECU is in a state that does not
permit flashing (e.g. vehicle speed > 0), the XCP Slave must acknowledge with an ERRor. The
actual flash process may not begin until the PROGRAM_START has been successfully acknowledged by the Slave.
PROGRAM_CLEAR: Call the current flash memory erasing routine
Before flash memory can be overwritten with new contents, it must first be cleared. The call of
the erasing routine via this command must be implemented in the ECU or be made available to
the ECU with the help of the flash kernel.
PROGRAM_FORMAT: Select the data format for the flash data
The XCP Master uses this command to define the format (e.g. compressed or encrypted) in which
the data are transmitted to the Slave. If the command is not sent, the default setting is noncompressed and non-encrypted transmission.
PROGRAM: Transfer the data to the XCP Slave
For the users who are very familiar with flashing via diagnostics: this command corresponds to
TRANSFERDATA in diagnostics. Using this command, data is transmitted to the XCP Slave, which
is then stored in flash memory.
57
58
59
Slave
Master
Request k
Part1
Part2
Part3
MIN_ST
MAX_BS
Response k
Request k+1
Time
Figure 47:
Representation
of the block
transfer mode
The use of such a method accelerates the procedure when transmitting large amounts of data
(UPLOAD, SHORT_UPLOAD, DOWNLOAD, SHORT_DOWNLOAD and PROGRAM). The Master can find
out whether the Slave supports this method with the request GET_COMM_MODE_INFO. You will
find more on this in ASAM XCP Part 2 Protocol Layer Specification 1.1.0.
60
61
62
63
64
One reason why an A2L file is needed has already been named: to allocate symbolic names to
addresses. For example, if a software developer has implemented a PID controller and assigned
the names P1, I1 and D1 in his application for the proportional, integral and differential components, then the calibrator should be able to access these parameters with their symbolic names.
Let us take the following figure as an example:
Figure 48:
Parameters in
a calibration window
The user can conveniently modify values using symbolic names. Another example is provided by
viewing signal variables that are measured from the ECU:
In the legend, the user can read the logical names of the signals. The addresses at which the
parameters were located in the ECU are of secondary importance in the offline analysis of values. Naturally, the correct address is needed to request the values in the ECU, but the numeric
value of the address itself is of no importance to the user. The user uses the logical name for
selection and visualization purposes. That is, the user selects the object by its name and the XCP
Master looks for the associated address and data type in the A2L.
Another attribute of a parameter might be the definition of a minimum or maximum value. The
value of the object would then have to lie within these limits. Imagine that you as the software
developer define a parameter that has a direct effect on a power output stage. You must now
prevent the user whatever the users reasons might be from configuring the output stage
that would result in catastrophic damage. You can accomplish this by defining minimum and
maximum values in the A2L to limit the permitted values.
Rules for conversion between physical and raw values are also defined in the A2L. You can visualize a simple example of such a conversion rule in a sensor that has an 8-bit value. The numeric
values output by the sensor lie between 0 and 255, but you wish to see the value as a percentage value. Mapping of the sensor value [0255] to [0100%] is performed with a conversion rule, which in turn is stored in the A2L. If an object is measured, which exists as a raw value
in the ECU and is also transmitted as such, the measurement and calibration tool uses the stored
formula and visualizes the physical value.
Besides scalar parameters, characteristic curves and maps are frequently used. Some might utilize a proximity sensor such as a Hall sensor, which determines distance as a function of magnetic field strength and you may wish to use this distance value in your algorithm. The magnetic
field and distance value do not run linear to one another. This nonlinearity of values would make
formulation of the algorithm unnecessarily difficult. With the help of a characteristic curve, you
can first linearize the values before you input the values into your algorithm as input variables.
Another application area for characteristic maps is their use as substitutes for complex computations. For example, if there is a relationship y = f(x) and the function f is associated with a lot
of computing effort, it is often simpler to simply compute the values over the potential range of
x in advance and store the results in the form of a table (= characteristic curve). If the value x
is now in the ECU, the value y does not need to be computed at the controllers runtime, rather
the map returns the result y to the input variable x. It may be necessary to interpolate between
two values, but that would be the extent of the calculations.
How is this characteristic curve stored in memory? Are all x values input first and then all y values? Or does storage follow the pattern: x1, y1; x2, y2; x3, y3 ? Since various options are
available, the type of memory storage is defined in a storage scheme in the A2L.
The convenience for the user comes from the ability to work with symbolic names for parameters, the direct look at the physical values and access to complex elements such as characteristic maps, without having to concern oneself with complex storage schemes.
Another advantage is offered by the communication parameters. They are also defined in the
A2L. In the communication between the measurement and calibration tool and the ECU, the
parameter set from the A2L is used. The A2L contains everything that the measurement and calibration tool needs to communicate with the ECU.
65
66
FIX_AXIS_PAR_DIST 0 1 8
/end AXIS_DESCR
/begin AXIS_DESCR
FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7
EXTENDED_LIMITS 0 7
READ_ONLY
BYTE_ORDER MSB_LAST
FORMAT %.0
FIX_AXIS_PAR_DIST 0 1 8
/end AXIS_DESCR
/begin IF_DATA CANAPE_EXT
100
LINK_MAP map3_8_8_uc 0xE0338 0x0 0 0x0 1 0x87 0x0
DISPLAY 0 0 255
/end IF_DATA
FORMAT %.3
/end CHARACTERISTIC
The ASCII text is not easy to understand. You will find a description of its structure in ASAM XCP
Part 2 Protocol Layer Specification 1.1.0 in chapter 2.
The sections below describe how to create an A2L. Let us focus on the actual contents of an A2L
and their meanings and leave the details of the A2L description language to an editor. The A2L
Editor that is supplied with CANape is used here.
67
68
In the A2L Editor (available as part of CANape or as a separate tool), the linker-map file is associated to the A2L. In a selection dialog, the user can now select those parameters from the map
file which it needs in the A2L: scalar measurement and calibration parameters, characteristic
curves and maps. The user can gradually add the desired parameters to the A2L step by step and
group them. Other object-specific information is also added using the editor.
What should be done when you modify your code, recompile it and link it? It is highly probable that the addresses of objects will change. Essentially, it is not necessary to generate a new
A2L. If you wish to have objects just added to the code also be available in the A2L, you must of
course add them to the A2L. Address updating is always necessary in the A2L. This is done with
the editor; it searches for the relevant entry in the linker-map file based on the name of the A2L
object, reads out the address and updates it in the A2L.
If your application changes very dynamically objects are renamed, data types are adapted,
parameters are deleted and others added then the manual work method is impractical. To generate an A2L from a C code, other tools are available for automatic processing.
On the Vector homepage you will find information on the ASAP2 Tool-Set with which you can
automate the generation of A2Ls from the source code in a batch process.
Here is an overview of possible commands that are used to find out something about the XCP
implementation in the Slave:
GET_DAQ_PROCESSOR_INFO
Returns general information on the DAQ lists: MAX_DAQ, MAX_EVENT_CHANNEL, MIN_DAQ
GET_DAQ_RESOLUTION_INFO
Maximum parameter of an ODT entry for DAQ/STIM, time interval information
GET_DAQ_EVENT_INFO (Event_channel_number)
Returns information for a specific time interval: Name and resolution of the time interval, number of DAQ lists that may be assigned to this time interval
GET_DAQ_LIST_INFO (DAQ_List_Number)
Returns information on the selected DAQ list: MAX_ODT, MAX_ODT_ENTRIES exist as predefined
DAQ lists
69
70
71
3 Calibration Concepts
3 Calibration Concepts
72
3 Calibration Concepts
ECU parameters are constant parameters that are adapted 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.
The calibration concept answers the question of how parameters in the ECU can be changed
during an ECUs development and calibration phases. There is not one calibration concept that
exists, rather several. Which concept is utilized usually depends very much on the capabilities
and resources of the microcontroller that is used.
Normally, parameters are stored in the production ECUs flash memory. The underlying program
variables are defined as constants in the software. To make parameters modifiable at runtime
during an ECUs development, additional RAM memory is needed.
A calibration concept is concerned with such questions as these: How do the parameters initially
find their way from flash to RAM? How is the microcontrollers access to RAM rerouted? What
does the solution look like when there are more parameters than can be simultaneously stored
in RAM? How are the parameters copied back into flash? Are changes to the parameters persistent, i.e. are they preserved when the ECU is turned off?
A distinction is made between transparent and non-transparent calibration concepts. Transparent means that the calibration tool does not need to be concerned with the above questions,
because all necessary mechanisms are implemented in the ECU.
Several methods are briefly introduced in the following.
Under some circumstances, with certain compilers it may be necessary to explicitly ensure that
parameters are always also stored in flash memory and not integrated in the code, for example and therefore do not appear at all in the linker-map file. Usually, one does not want to leave
to chance where a constant is created in flash memory. The necessary means for accomplishing this are almost always compiler-specific pragma instructions. To prevent the compiler from
embedding them in the code, it is generally sufficient to use the volatile attribute for constant parameters. A typical definition of a flash constant appears as in the following example:
C code example:
#pragma section FLASH_Parameter
volatile const float factor = 0.5;
It is normally not possible to calibrate parameters in flash online. Indeed, most microcontrollers
are able to program their flash themselves, which is necessary for the purposes of re-programming in the field. Nonetheless, flash memory always has the property of being organized into
larger blocks (sectors), which can only be erased as a whole. It is practically impossible to flash
just individual parameters, because the ECU normally does not have the resources to buffer the
rest of the sector and reprogram it. In addition, this process would take too much time.
Some ECUs have the ability to store data in what is known as an EEPROM memory. In contrast to
flash memories, EEPROM memories can erase and program each memory cell individually. The
amount of available EEPROM memory is always considerably less than the available flash memory and it is usually limited to just a few kilobytes. EEPROM memory is often used to store programmable parameters in the service shop or to implement a persistence mechanism in the
ECU, e.g. for the odometer. Online calibration would be conceivable here, but it is seldom used,
because access to EEPROM cells is relatively slow and during the booting process EEPROM parameters are usually copied over to RAM memory, where it is possible to access them directly. ECUs
which have no EEPROM memory often implement what is known as an EEPROM emulation. In
this method, multiple small flash sectors are used in alternation to record parameter changes,
so that the last valid value can always be determined. Online calibration would also be conceivable with this method.
In both cases, the relevant memory accesses would then be intercepted in the software components of the XCP driver and implemented with the software routines of the EEPROM or the
EEPROM emulation. The Vector XCP Professional driver offers the software hooks needed for this.
73
74
3 Calibration Concepts
FLASH
RAM
Calibration RAM
Parameters
Figure 50:
Initial parameter
setting in RAM
The calibration RAM does not need to consist of a fully contiguous RAM area. It may also be distributed into multiple areas or even in any desired way. Nonetheless, it offers significant advantages for organizing the parameters in just a few contiguous RAM areas and isolating them from
other RAM parameters such as changing state variables and intermediate results. This is especially important if offline calibration of the calibration RAM with a hex file should be enabled.
At the users request, the calibration tool must be able to load the parameters that were modified offline into the ECU during the transition from offline calibration to online calibration.
This case occurs very frequently. For example, when calibrators reconnect with their ECU on the
next work day, they want to resume work at the point at which they stopped the evening before.
However, booting of the ECU causes the flashed contents to be copied to the RAM as an initial
dataset. To let users resume with work accomplished on the previous day, the parameter set
file saved the previous evening in the ECUs RAM must be loaded. This loading process may be
time optimized by limiting the number of necessary transmissions to a minimum. It is advantageous here if the tool can quickly and reliably determine by forming a checksum over larger
contiguous areas whether there are differences. If there are no differences between the calibration RAM contents in the ECU and the file modified using the tool, this area does not need
to be transferred. If the memory area with the calibration parameters is not clearly defined, or
if it includes parameters that are modified by the ECU software, a checksum calculation always
shows a difference and the parameter values are transmitted, either from the ECU to the XCP
Master or in a reverse direction. Depending on the transmission speed and amount of data, this
transmission could take several minutes.
Another advantage of clearly defined memory segments is that the memory area for initial values in flash memory can be used for offline calibration. The contents of the flash memory are
defined using flashable hex files. If the calibration tool knows the location of parameters in the
hex file, it can modify their values and implement new initial values in the ECU by flashing the
modified hex file.
The calibration tool not only needs to know the location of parameters in RAM, but also the initial values in flash. A prerequisite is that the RAM memory segment must be initialized by copying from an identically laid out memory segment in flash, as is the usual practice in most compilers/linkers. If the addresses of parameters in RAM are in the A2L file, it is only necessary to
let the tool know the offset to the start address of the calibration RAM, which it must add to get
to the start address of the relevant flash area. This offset then applies to each individual parameter in the A2L.
The calibration tool can then either generate flashable hex files for this area itself, or it can
place them directly on the original hex files of the linker to modify the initial values of parameters in the hex file.
75
76
3 Calibration Concepts
CONNECT
SET_CAL_PAGE XCP to RAM
CALC_CHECKSUM
When a difference has been detected in the checksum calculation over the RAM area, first the
user is normally asked how to proceed. Should the contents of ECU RAM be sent to the Master, or
should the contents of a file on the Master page be sent to the ECUs RAM? If the user decides to
write the offline changes to the ECU, the subsequent process appears as follows:
ECU should use the dataset of the flash page
Copy file from Master to the RAM page
ECU should use the dataset of the RAM page
Afterwards, the memory page is always switched over to RAM, so that parameters can be
modified. But the user can also explicitly indicate which memory page should be active in the
ECU. For example, the behavior of the RAM parameter set can be compared to that of the flash
parameter set, or in an emergency it can be switched back to a proven parameter set in flash at
lightning speed.
77
78
3 Calibration Concepts
FLASH
Pointertable
Parameters
RAM
Figure 51:
Initial situation
after booting
79
When the user selects a parameter from the A2L file for the first time after booting and wishes
to write access it, this triggers a copying operation within the ECU first. The XCP Slave determines that the address to which the access should be made is located in the flash area, and it
copies the parameter value to the calibration RAM. A change is also made in the pointer table
to ensure that the application no longer gets the parameter value from flash, but instead from
the RAM area:
FLASH
Pointertable
RAM
Figure 52:
Pointer change and
copying to RAM
Parameters
The application continues to get the parameter value via the pointer table. But since the pointer
indicates the RAM address, the value is retrieved from there. As a result, the user can change
the parameter value via XCP and observe the effects of the change in the measurement. The disadvantage of this method is that an entry in a pointer table must be available for each parameter and in turn the method is associated with substantial additional RAM memory requirements
for the pointer table.
The next figure illustrates the problem. Three parameters of a PID controller (P, I and D) are contained in an ECUs flash area. The RAM addresses and parameter values in RAM are also already
changed in the pointer table.
Parameter Flash
Pointertable
RAM
Addr.
Content
Addr.
Addr.
Content
0x0000100A
0x11
0x000A100A
0x000A100A
0x44
0x000012BC
0x22
0x000A100B
0x000A100B
0x55
0x00007234
0x33
0x000A100C
0x000A100C
0x66
Calibration concepts are very important, because RAM resources are scarce. Large RAM pointer
tables would make a concept self-defeating.
80
3 Calibration Concepts
To avoid having to create a pointer for each individual parameter and having the method be
used as such, the parameters can be combined into structures. This requires just one pointer
per structure. When the user selects a parameter, not only is this parameter copied to RAM, but
so is the entire associated structure. The granularity of the structures is of key importance here.
With large structures only a few pointers are necessary. In turn, this means that with the decision for a specific parameter, a rather large associated structure is copied to the RAM area and
this can cause the limits of calibration RAM space to be reached quickly.
Example:
The calibration RAM should be 400 bytes in size. Four structures are defined in the software with
the following parameters:
Structure A: 250 bytes
Structure B: 180 bytes
Structure C: 120 bytes
Structure D: 100 bytes
When the user selects a parameter from structure A, the 250 bytes are copied from flash to the
calibration RAM, and the user has XCP access to all parameters located in structure A. If the calibration task is limited to the parameters of this structure, the calibration RAM is fully sufficient.
However, if the user selects another parameter located in a different structure, e.g. structure
C, these 120 bytes must also be copied to the calibration RAM. Since the calibration RAM can
handle 400 bytes, the user can access all parameters of structures A and C simultaneously.
If another selected parameter is not located in structure C, but rather in structure B, the 180
bytes of structure B would have to be copied to RAM in addition to the 250 bytes of structure A.
However, since the space in RAM is inadequate for this, the user indeed has access to the parameters of structure A, but not to the data of structure B, because the ECU cannot execute the copy
command.
3.5.2 Double Pointer Concept
A disadvantage of the single pointer concept is that memory page swapping is not easy to implement. The calibration tool could simply describe the pointer table completely for page swapping, but this is not feasible in a short period of time without resulting in temporary inconsistencies and side effects. A tool-transparent implementation would double the memory space
requirement for the pointer table, because when swapping the memory page into flash, a copy
of the previous pointer table would have to be created with RAM pointers.
For applications with large pointer tables, a transparent implementation or a fully consistent
swapping, there is the option of extending the method to a double pointer concept. To explain
how this is done, we return once again to the initial RAM setting.
81
Figure 50 represents the pointer table. It lies in RAM. As already mentioned, this table must be
copied from flash into RAM. As a result, this table lies in flash memory. If another pointer is now
used (a table pointer), which points to either the pointer table in RAM or in flash, one arrives
at a double pointer solution.
FLASH
Pointertable
FLASH
RAM
Pointertable
Tablepointer
RAM
Figure 54:
Double pointer concept
The parameter values are initially accessed via the table pointer. If the table pointer indicates
the pointer table in RAM, the application essentially accesses the actual parameters via the contents of the RAM pointer table. The low access speed and the creation of more program code are
disadvantages of this solution.
82
83
84
When ECU calibrators think about the use of XCP, they are usually fixated on use of the protocol in the ECU.
Simulink
Slave
Slave
XCP
PC
Slave
Master
Prototype or
ECU Hardware
Measurement/
Calibration
Hardware*
EXE/DLL
Slave
HIL/SIL Systems
Slave
* Debug Interfaces, Memory Emulator, ...
Figure 55:
Application areas and
application cases
In a survey of development processes, one encounters many different solution approaches for
the development of electronics and software. HIL (Hardware in the Loop), SIL (Software in the
Loop) and Rapid Prototyping are keywords here and they describe different scenarios. They
always have a plant and a controller in common.
Offset
Reference Variable
(Set Value)
Manipulated
Variable
Controller
Disturbance
Variable
Plant
Controlled Variable
(Actual Value)
In the context of automotive development, the controller is represented by the ECU and the
plant is the physical system to be controlled such as the transmission, engine, side mirrors, etc.
The rough subdivision is made between different development approaches according to whether
the controller or the plant runs in real or simulated mode. Some combinations will be described
in greater detail.
85
Simulink
Controller Model
Plant Model
Figure 57:
Model in the Loop
in Simulink
In this development environment, both the controller and the plant are simulated as a model. In
the example shown, both models run in Simulink as the runtime environment. The capabilities
of the Simulink runtime environment are available to you for analyzing the behavior.
To realize the convenience of a measurement and calibration tool like CANape in an early development phase, an XCP Slave can be integrated in the controller model. In an authoring step,
the Slave generates the A2L that matches the model and the user already has the full range of
convenient operating features with visualization of process flows in graphic windows, access to
characteristic curves and maps and much more.
Simulink
CANape
A2L
Controller Model
Simulink
XCP Server
Plant Model
Figure 58:
CANape as
measurement and
calibration tool with
Simulink models
Neither a code generation step nor instrumentation of the model is necessary for this. Time
stamps are also included with transmissions over XCP. CANape completely adapts to the time
behavior of the Simulink runtime environment here. Whether the model is running faster or
slower than in real time is of no consequence. For example, if the functional developer uses the
Simulink Debugger in the model to step through the model, CANape still takes the time transmitted via XCP as the reference time.
86
Simulink
Controller Model
Plant Model
Code generation
Figure 59:
Software in the
Loop with Simulink
environment
Controller Model
Windows DLL
In this development step, code is generated from the model of the controller, which is then
used in a PC-based runtime environment. Naturally, the controller may also have been developed without any sort of model-based approach. The plant continues to be simulated. XCP can
be used to measure and calibrate the controller. If the controller originates from a Simulink
model, a code generation step (Simulink Coder with the target CANape) is used to generate
the C code for a DLL and the associated A2L. If the Controller development is conducted based
on manually written code, it is embedded in a C++ project that is delivered with CANape.
After compiling and linking, the DLL is used in the CANape context. With the support of the XCP
connection, the algorithms in the DLL can be measured and calibrated exactly as if the application were already integrated in an ECU.
Simulink
Controller Model
Plant Model
Code generation
A2L
CANape
Controller Model
Windows DLL
Figure 60:
CANape as SIL
development platform
87
Controller Model
HIL Platform
I/O
Plant Model
Figure 61:
HIL solution
ECU
The controller algorithm runs in a microcontroller platform (e.g. the ECU), while the plant continues to be simulated. Depending on the parameters and the complexity of the plant and the
necessary I/O, requirements of the HIL platform and the associated costs can rise steeply. Since
the ECU runs in real time, the model of the plant must also be computed in real time.
To now introduce XCP for optimization appears trivial, because another ECU is being added. The
whole system looks like this:
A2L
Controller Model
HIL Platform
I/O
CANape
Plant Model
ECU
Figure 62:
HIL with CANape
as measurement
and calibration tool
From CANape, the user has access to the algorithms in the ECU over XCP.
88
The Vector Tool CANoe is also used by many customers as a HIL system. With CANoe, a HIL system might look like this:
CANoe RT User PC
Ethernet
CANoe RT Server
CAN
Plant Model
Digital I/O
Analog I/O
LIN
A2L
MOST
FlexRay
XCP
ECU
CANape
Figure 63:
CANoe as HIL system
The ability to access XCP data directly from CANoe for testing purposes results in the following
variant as well:
CANoe RT User PC
A2L
Ethernet
CANoe RT Server
CAN
Plant Model
Digital I/O
Analog I/O
LIN
MOST
XCP
FlexRay
ECU
Figure 64:
CANoe as HIL
system with XCP
access to the ECU
Here the model of the plant runs on the CANoe real-time server. At the same time, XCP access
to the ECU is also realized from CANoe. This gives a tool simultaneous access to the plant and
the controller.
89
To round out the picture, yet another HIL solution option should be mentioned. The plant might
also run as a DLL in CANape. This gives the user full access to the plant and to the controller
over XCP.
ECU
CANape
A2L
Plant Model
Windows DLL
XCP
Plant
A2L
XCP
ECU
Controller Model
A2L
CANape
EVA Board
XCP
I/O
Plant
The concepts Rapid and Prototyping describe the task very well. The aim is to develop a
functional prototype as quickly as possible, to use and test it in the runtime environment. This
just requires simple work steps throughout the entire process.
90
In the literature, the RCP approach is frequently subdivided into two areas: fullpassing and
bypassing.
As depicted in Figure 66, the entire controller runs on separate real-time hardware. This method
is known as fullpassing, because the entire controller runs on the controller hardware. It must
have the necessary I/O to be able to interface with the plant. Very often, it is only possible to
fulfill technical requirements for the I/O with suitable power electronics.
It is not only the I/O that represents a challenge; often functional elements of the ECU software
(e.g. network management) are needed to enable functionality in a more complex network.
However, if a complete ECU is used for Rapid Control Prototyping instead of a general controller platform, the complexity of the flash process, the size of the overall software, etc. all work
against the requirement for Rapid development.
In summary: the use of an entire ECU as the runtime environment for the controller offers the
advantage that the necessary hardware and software infrastructure for the plant exists. The disadvantage lies in the high degree of complexity.
The concept of bypassing was developed to exploit the advantages of the ECU infrastructure
without being burdened by the disadvantages of high complexity.
4.5 Bypassing
In Figure 67, the ECU is connected to the plant. The necessary I/O and software components are
available in the ECU. In the bypassing hardware, an algorithm A1 runs, which occurs in Version
A of the ECU. A1 is a new variant of the algorithm and should now be tried out on the real plant.
ECU
Bypassing
Hardware
A2L
CANape
XCP
Bypassing Hardware
A2L
XCP
I/O
Controller Model
ECU
Plant
91
4.5 Bypassing
The bypassing hardware (a VN8900 device in the figure) and the ECU are interconnected over
XCP. One goal here is to get the data needed for algorithm A1 from the ECU by DAQ; another
goal is to stimulate the results of A1 back into the ECU. The following figure illustrates the schematic flow:
Bypassing Hardware
Bypassing
Coordinator
2.
Algorithm A1
3.
1. XCP 4.
Algorithm A
ECU
Figure 68:
Bypassing flow
Depicted in the ECU is a blue function block in which the algorithm A runs. To ensure that A1 can
now be used, the data enters algorithm A as an input variable and it is measured from the ECU
by DAQ. In step 1, the bypassing coordinator accepts the data and in step 2 it passes the data to
algorithm A1. A1 is computed by the bypassing hardware and in step 3 the result is passed back
to the bypassing coordinator; in step 4, it is transmitted to the ECU by STIM. The data is written
to the location at which the next function block in the Slave expects its input variables. This
makes it possible to use the value computed by algorithm A1 and not from A in the ECUs overall control process. This method permits using a combination of the rapid substitution of algorithms on the bypassing hardware that incorporates the I/O and the ECUs basic software.
92
Of course, the performance limits of an XCP-on-CAN driver also affect bypassing. If short bypassing times are needed, access to the ECU by DAQ and STIM may also be performed via the controllers debugging or trace interfaces. The Vector VX1000 measurement and calibration hardware converts the data into an XCP-on-Ethernet data stream from the controller interface. In
this process, up to one megabyte of data can be transported into the ECU.
Bypassing
Hardware
A2L
CANape
XCP
Bypassing Hardware
XCP
I/O
Controller Model
ECU
Plant
Figure 69: Bypassing with real-time bypassing hardware and fast ECU access
93
Parameter
MDF
test drive
Application
5. Analyze
1. Set parameters
2. Start
CANape
Simulink/
DLL
4. Measurement data
Slave
New
MDF
Figure 70:
Short calibration
cycles with
virtual ECUs
94
After the calculation has been completed, a new measurement file is available to the user for
analysis of ECU behavior. The length of time of the new measurement file precisely matches the
length of the input measurement file. If the duration of a test drive is one hour, the algorithm
on the PC might calculate the entire test drive in just a few seconds. Then a measurement result
exists, which corresponds to a test of one hour duration. Based on the data analysis, the user
makes decisions about parameterization and the iteration cycle is repeated.
CANape
Parameterization
via XCP
Set values in
workspace
Start
Start
Send measurement
data
Calculate model
Receive new
measurement data
Send measurement
values from the model
Analyze the
new data
Figure 71:
Process flow
with virtual ECUs
To shorten the iteration cycles, the algorithm is always stimulated with the same data. That
makes the results with different parameters much more comparable, because the results are
only influenced by the parameters that differ.
This process can of course be automated. The integrated script language of CANape performs an
analysis of the measurement results, from which parameter calibration settings are derived and
automatically executed. It is also possible to have the process controlled by an external optimization tool such as MATLAB over the CANape automation interface.
95
96
97
98
To make it possible for an ECU to communicate over XCP, it is necessary to integrate an XCP driver
in the ECUs application. The example described below is of the XCP driver which you can download free of charge at the Download Center of the Vector website (www.vector.com/xcp-driver).
This packet also contains some sample implementations for various transport layers and target platforms. The driver consists of the protocol-Layer with the basic functionality needed for
measurement and calibration. It does not include features such as Cold Start Measurement,
Stimulation or flashing. You can purchase a full implementation as a product that is integrated
in the Vector CANbedded or AUTOSAR environment.
The XCP protocol layer is placed over the XCP transport layer, which in turn is based on the actual
bus communication. The implementation of the XCP protocol layer only consists of a single C
file and a few H files (xcpBasix.c, xcpBasic.h, xcp_def.h and xcp_cfg.h). The examples include
implementations for various transport layers, e.g. Ethernet and RS232. In the case of CAN, the
transport layer is normally very simple and the various XCP message types are mapped directly
to CAN messages. There are then separate fixed identifiers for the Tx and Rx directions.
The software interface between the transport and protocol layers is very simple. It contains just
a few functions:
> When the Slave receives an XCP message over the bus, it first arrives in the communication
driver, which routes the message to the XCP transport layer. The transport layer informs the
protocol layer about the message with the function call XcpCommand().
> If the XCP protocol layer wishes to send a message (e.g. a response to an XCP command from
the Master or a DAQ message), the message is routed to the transport layer by a call of the
ApplXcpSend() function.
> The transport layer informs the protocol layer that the message was successfully sent by the
function call XcpSendCallBack().
99
XcpSendCallback
XcpCommand
ApplXcpSend
ApplXcpGetPointer
XcpBackground
XcpInit
XcpEvent
Application
Physical Layer
Bus
Figure 72:
Incorporating
the XCP Slave
in the ECU code
The interface between the application and the protocol layer can only be implemented via four
functions:
> The application activates the XCP driver with the help of XcpInit(). This call is made once in
the starting process.
> With XcpEvent(), the application informs the XCP driver that a certain event has occurred
(e.g. End of a computational cycle reached).
> The call XcpBackground() lets the XCP driver execute certain activities in background (e.g.
calculation of a checksum).
> Since the addresses in A2L files are always defined as 40-bit values (32-bit address, 8-bit
address extension), the XCP driver uses the function ApplXcpGetPointer() to obtain a pointer
from a A2L-conformant address.
These interfaces are sufficient to integrate basic functionalities for measurement and calibration. Other interfaces are only needed for extended functions such as page swapping, identification or seed & key. They are described in detail in documentation for the driver.
100
101
102
103
104
Download
Upload
Literature
XCP is specified by ASAM (Association for Standardisation of Automation and Measuring Systems).
You will find details on the protocol and on ASAM at: www.asam.net
Web Addresses
Standardization committees:
> ASAM, XCP protocol-specific documents, A2L specification, www.asam.net
Supplier of development software:
> MathWorks, information on MATLAB, Simulink and Simulink Coder, www. mathworks.com
> Vector Informatik GmbH, demo version of CANape, free of charge and openly available XCP
driver (basic version), comprehensive information on the topics of ECU calibration, testing
and simulation, www.vector.com
105
106
Table of Figures
Table of Figures
Figure 1: Fundamental communication with a runtime environment
Figure 2: The Interface Model of ASAM
Figure 3: An XCP Master can simultaneously communicate with multiple Slaves
Figure 4: Subdivision of the XCP protocol into protocol layer and transport layer
Figure 5: XCP Slaves can be used in many different runtime environments
Figure 6: XCP packet
Figure 7: Overview of XCP Packet Identifier (PID)
Figure 8: XCP communication model with CTO/DTO
Figure 9: Message identification
Figure 10: Time stamp
Figure 11: Data field in the XCP packet
Figure 12: The three modes of the XCP protocol: Standard, Block and Interleaved mode
Figure 13: Overview of the CTO packet structure
Figure 14: Trace example from a calibration process
Figure 15: Transfer of a parameter set file to an ECUs RAM
Figure 16: Hex window
Figure 17: Address information of the parameter Triangle from the A2L file
Figure 18: Polling communication in the CANape Trace window
Figure 19: Events in the ECU
Figure 20: Event definition in an A2L
Figure 21: Allocation of Triangle to possible events in the A2L
Figure 22: Selecting events (measurement mode) for each measurement parameter
Figure 23: Excerpt from the CANape Trace window of a DAQ measurement
Figure 24: ODT: Allocation of RAM addresses to DAQ DTO
Figure 25: DAQ list with three ODTs
Figure 26: Static DAQ lists
Figure 27: Dynamic DAQ lists
Figure 28: Event for DAQ and STIM
Figure 29: Structure of the XCP packet for DTO transmissions
Figure 30: Identification field with absolute ODT numbers
Figure 31: ID field with relative ODT and absolute DAQ numbers (one byte)
Figure 32: ID field with relative ODT and absolute DAQ numbers (two bytes)
Figure 33: ID field with relative ODT and absolute DAQ numbers as well as fill byte
(total of four bytes)
Figure 34: Definition of which bus nodes send which messages
Figure 35: Representation of a CAN network
Figure 36: Example of XCP-on-CAN communication
Figure 37: Representation of an XCP-on-CAN message
Figure 38: Nodes K and L are redundantly interconnected
Figure 39: Communication by slot definition
Figure 40: Representation of a FlexRay communication matrix
Figure 41: Representation of the FlexRay LPDUs
Figure 42: Allocation of XCP communication to LPDUs
Figure 43: XCP packet with TCP/IP or UDP/IP
Figure 44: XCP-on-SxI packet
8
9
10
14
15
19
19
20
21
21
22
24
25
30
31
32
33
34
35
35
36
36
37
38
39
39
40
41
42
43
43
43
44
45
46
47
47
48
48
49
50
51
52
53
107
Table of Figures
54
56
59
64
64
74
78
79
79
81
84
84
85
85
86
86
87
87
88
88
89
89
90
91
92
93
94
99
108
109
110
Index
Index
A
A2L
Bandwith optimization
Bus load
BYP
Bypassing
34
34
104
44, 9092
DAQ
DBC
DOWNLOAD
DTO
ECU
EEPROM
ERR
EV
Event
FIBEX
Flash memory
FLX_CHANNEL
FLX_LPDU_ID
FLX_SLOT_ID
Fullpassing
4951
16, 17, 5457, 60
50
50
50
90
GET_CAL_PAGE
GET_DAQ_PROCESSOR_INFO
HIL
CAN
Linking
LPDU
MIL
MTA
ODT
OFFSET
PAG
Page
PGM
PID
Polling
RAM
Reboot
RES
25, 55
44, 58, 68
84, 8789
72, 86
50
85
30, 104
111
Index
Segment
55, 56
SEGMENT_NUMBER
55
SERV
29, 104
SET_CAL_PAGE
25, 55
SHORT_UPLOAD
30, 33, 59
SIL
84, 86
STIM
33, 41, 42, 44, 58, 68, 91, 92, 104
Stimulation
29, 61, 93
Task
TCP/IP
UDP/IP
USB
Useful bytes
100
51, 52, 104
51, 52, 104
53, 104
29, 38, 45, 47
Virtual ECU
93
Volatile
72, 73
VN8900
91
VX1000 9, 92
V 1.0 4/2013
www.vector.com