Image Processing Reference
In-Depth Information
theECU.hispageiscalledtheactivepagefortheECU'sapplication.hesameholdstrueforXCP
itself as well (active XCP page). XCP ensures that concurrent access to the same page by the ECU's
application and XCP itself is prevented.
Via XCP CMD packets, the XCP master can instruct the XCP slave to switch active pages of the
same segment (i.e., to make a page which has previously not been the active one the new active page)
and to copy data between pages of the same or of different memory segments.
This way the calibration data used for the slave ECU's control loops, for example, can be altered
upon run-time under control of the XCP master.
18.6.1.5 Flash Programming
To facilitate the exchange of the current image of the application program in the slave ECU's
nonvolatile memory, XCP defines special commands (exchanged via XCP command packets) for
performing flash (re-)programming. The following list contains a short description of the main
commands used in flash programming:
PROGRAM_START
: This indicates the beginning of a programming sequence of the slave ECU's
nonvolatile memory.
PROGRAM_CLEAR
: This clears a part of the slave ECU's nonvolatile memory (required before
programming new data into this part of memory).
PROGRAM_FORMAT
:Itisusedtospecifytheformatforthedatathatwillbetransferredtotheslave
ECU (e.g., used compression format, used encryption algorithm, etc.).
PROGRAM
:hiscommand,whichisissuedinaloopaslongasthereisstilldataavailablethatneed
to be programmed, is used to program a given number of data bytes to a given address within the
slave ECU's nonvolatile memory.
PROGRAM_VERIFY
: This verifies that the programming process has completed successfully by,
for example, calculating a checksum over the programmed memory area.
PROGRAM_RESET
: his indicates the end of the programming sequence and optionally resets the
slave ECU.
By means of these flash programming XCP commands, a flash download process for the ECU's
development stage can be implemented. In-system flash programming in series cars, however, is
usually performed via the diagnostics protocol (see Section ..).
18.7 AUTOSAR
The development partnership AUTOSAR is an alliance of OEM manufacturers, major supplier
companies, and tool vendors working together to develop and establish an open industry standard
for an automotive electronic architecture, which is intended to serve as a basic infrastructure for the
management of (soft and hard real-time) functions within automotive applications.
Thus far, AUTOSAR versions ., ., ., and . have been released. For versions . and
., a dedicated proof-of-concept implementation has been performed and integrated in a sample
application.
The AUTOSAR software architecture makes a rather strict distinction between application soft-
ware and basic or system software. While the “basic (or system) software” provides functionality
like communication protocol stacks for automotive communication protocols (e.g., FlexRay [,]),
a real-time-operating system, and diagnostic modules, the “application software,” comprises all
application-specific software items (i.e., control loops, interaction with sensor and actuators, etc.).
This way, the basic or system software provides the foundation, the application software is built upon.
