ODX-based flash solution

Software engineering

The described flash solution was approved in practice using an ECU for
construction machines. The powertrain ECUs exchange data via a
CAN-based J1939 network.

Figure 1: Liebherr Mining Excavator

R995 without license to operate on
open public highways

N on-road mobile machines (NRMM) that are powered by

heavy-duty diesel engines with emission control sys-
tems are controlled by embedded electronic control units
NRMM ECUs usually employ a CAN-based com-
munication technology specified in the SAE J1939 set
of recommended practices. The ECUs of the engine, the
(powertrain ECUs). These powertrain ECUs exchange transmission, and the emission control system are part of
data via a CAN-based J1939 network and are connected the J1939 network. For maintenance and service, CAN
to control units that are especially made for NRMM appli- provides access to the powertrain and the entire control
cations. Modern control units are connected to the pow- system even if the ECUs are installed somewhere in the
ertrain CAN and support a diagnostic protocol that comes machine. External test equipment (a tester) is connected
with the capability of reprogramming the flash memory. to the CAN network of the machine (Figure 3). If both the
A control system consists of one or more embedded tester and the ECU support the same diagnostic protocol,
ECUs that process data according to the IPO (input-pro- the tester can send a diagnostic service request to an
cessing-output) principle. On NRMM, typical input data are ECU and the ECU answers with either a positive or a
physical values that are measured by sensors (e.g. tem- negative response. This kind of data communication, usu-
perature, pressure, revolution speed). Typical output data ally referred to as diagnostic communication, is specified
are for drive displays, lamps, or electro-hydraulic compo- in a diagnostic protocol, such as UDSonCAN. UDSonCAN
nents, such as on/off or proportional solenoid valves. The is short for Unified Diagnostic Services on Controller Area
NRMM control system consists of one or more embedded Network and is specified in ISO14229.
ECUs. The basic architecture of an embedded ECU con-
sists of a central processing unit (CPU), random access External test equipment components
memory (RAM), read-only memory (ROM), inputs, outputs,
power supply, and a connection to the in-vehicle network – Figure 3 illustrates how external test equipment is con-
in this example CAN. nected to the machine: A vehicle communication interface

42 CAN Newsletter 3/2015

 The application talks to the ECUs by sending di-
agnostic service requests and receiving the responses.
Depending on the use case, different tester applications
can be created on the same set of D-Server and ODX
data.
Today, the capability to reprogram ECUs is a must

the MVCI D-Server contains a job processor for the ex-

ecution of Java jobs and a flash data processor that is
specialized to support the programming of flash memory.
Alternatively to Java, the reprogramming application can
be created as OTX sequences or simply as C/C++ code.
Figure 2: Basic architecture of an embedded ECU In any case, the result is an ODX-based flash solution
(flashtool) for NRMM control systems.
(VCI) is connected to the USB port of a PC, and the VCI
is connected to the DLC (data link connector), which pro- Implementation example
vides access to the CAN network. Figure 4 illustrates the
software components of a tester. In the context of this The Compact Control Unit CCU 70 of Liebherr Elektronik
article, the application, the D-Server API, the MVCI D- is a programmable ECU, which was specially developed
Server, the D-PDU API, and the ODX data are of impor- for applications in mobile machinery and commercial ve-
tance. hicles. These use cases require reliability even under ex-
ODX is short for Open Diagnostic Data Exchange treme environmental conditions such as vibration, dirt,
and specified in ISO 22901. The ODX data file con- humidity, salt spray, or electromagnetic influence. The
tains the description of the ECUs in an internationally IP rating of the connected ECU is IP6K9K. The CCU is
standardized format. It contains at least the diagnostic available with three CAN and one Ethernet interfaces, up
protocol(s) and the communication parameters for the di- to 70 inputs and outputs, and it comes with 4-MiB flash
agnostic communication, e.g. for UDSonCAN. The MVCI memory. CCU 70 supports both J1939 for the on-board
D-Server executes the application and processes the communication with other ECUs (e.g. another CCU or the
ODX data. It also connects the application with the VCI, engine controller) and UDSonCAN for diagnostic com-
and therefore with the ECU(s). munication with external test equipment.
 ODX data and flashware
Software engineering

Figure 6 illustrates the 8 categories of an ODX database.

The ODX category Flash is the only ODX database cate-
gory that is solely used for reprogramming. The other ODX
categories are also used for other diagnostic applications.
The most important categories are the Communication Pa-
rameter Specification and the Diagnostic Layer Container
(DLC). Figure 6 shows the internal structure of a Diagnos- Figure 3: External Test Equipment is connected to the CAN
tic Layer Container. Because ODX describes the data for- of the machine
mat, not the content, it depends on the author if and how
the ODX categories are used. For the description of a sin-
gle ECU, at least a Communication Parameter Specifica-
tion, one DIAG-Layer, and – for reprogramming – the ODX
category Flash must contain data for the D-Server. For the
purpose of processing by the D-Server, the ODX data has to
be converted in a binary runtime equivalent (*.sod). The run-
time database with the description of the CCU70 is named
CCU70.sod.
ODX data files can contain one or more ECU descrip-
tions, even with different diagnostic protocols (communi-
cation parameters, request/response definitions). For the
purpose of diagnostic communication, the MVCI D-Server
not only needs to know the parameters of the VCI and the
physical location of the ECU in the vehicle, but also the loca-
tion of the ECU in the database. This information is provided Figure 4: The software components of external test
as a Logical Link in the application software of the flashtool. equipment
Flashware is the data that is programmed in the flash
memory in the end. It contains executable machine code example, 29-bit CAN-Identifiers are used. In the following,
and configuration data. The ECU application software pro- the reprogramming sequence for a control system with one
grammer creates a source code and uses a compiler or as- CCU is described: The first step is to start the LICoS Flash-
sembler to convert the source code to machine code, which -
is a HEX file that is then used to be programmed to the flash er supply off and on. The CCU boots and the boot loader
memory by a flashtool. The data format of the flashware can starts reading the CAN messages. It looks for a so-called
be binary, Intel Hex, or Motorola S. Force Download (FD) message (FD1 or FD2) that is sent
The ODX category Flash for the CCU contains the defi- on the CAN network by the flashtool.
nition of flashware with the data format Motorola S, usual- FD1 is used if the control system contains only one
ly referred to as S-records. S-record files can be identified CCU, FD2 if the control system contains more than one
by their file extension name *.s19. Figure 7 shows a small CCU. The FD message has to be sent by the flashtool with
excerpt of the CCU S-record file. In this example, the data a cycle time of at least 10 ms. If the CCU receives either
field contains FFh, meaning that the records do not con- FD1 or FD2 within 50 ms, the boot loader firmware pre-
tain executable machine code. The first two characters of pares the reprogramming sequence. If the boot loader re-
the S-record (S3) contain the information that this record ceives the FD1 message, it sets an output of the CCU (LED
has a 4-byte memory address and contains data. The two blinks) and waits for the first UDS request, which is the re-
characters after the S3 are the hex-coded byte-count. The quest to transition into the extended diagnostic session.
byte-count contains the number of bytes that follow the The CCU answers the request with a positive re-
byte-count. Here, the byte-count reads 25h (37d), which sponse and transitions into the extended diagnostic ses-
stands for the 4-byte memory address, 32 data bytes, and 1 sion. In that session, the CCU requires a security access.
byte for the checksum. For that purpose, the flashtool sends a request to get the
Only the 32 data bytes per S-record are programmed seed (securityAccess
to the flash memory. The memory address ends with 00h, > requestSeed). The
3Fh, FFh, FFh, representing the 4 MiB of flash memory. The CCU answers with a
starting memory address is 00h, 10h, 00h, 00h, meaning positive response and
that the reprogramming covers only 3 MiB of the available 4 sends the seed as a
MiB flash memory. 64-bit data parameter
in the response. The
Reprogramming sequence flashtool takes the seed
and calculates the key
If there is only one CCU connected to the CAN network, using a C-DLL that
preconfigured CAN-Identifiers for the request and response contains the seed-key- Figure 5: Liebherr Compact
services can be used by the flashtool and the CCU. In this calculation algorithm. Control Unit CCU 70

44 CAN Newsletter 3/2015

International trade magazine lift
for the technology of elevators
and escalators report

PLE
A
CON SE
US TACT
T
A S O GET
PEC
I
COP MEN
Y!

Lift-Report takes part regularly in all major

fairs and trade events – worldwide.
Take the advantage of the magazine and make
new contacts in the lift industry.

vfz
VERLAG
Hengsener Straße 14 . 44309 Dortmund . Germany
Phone: +49(0)231/92 50 55 50 . [email protected]
www.lift-report.de
 References
Software engineering

[1] ISO 14229-1:2013: Road vehicles – Unified

diagnostic services (UDS) –Part 1: Specification and
Requirements
[2] ISO 22900-2:2009: Road vehicles – Modular vehicle
communication interface (MVCI) – Part 2: Diagnostic
protocol data unit application programming interface
(D- PDU API)
[3] ISO 22900-3:2012: Road vehicles – Modular vehicle
communication interface (MVCI) – Part 3: Diagnostic
server application programming interface (D-Server
API)
[4] ISO 22901-1:2008: Road vehicles – Open diagnostic
data exchange (ODX) – Part 1: Data model specification
[5] P.Subke & C.Marscholik: Road vehicles – Diagnostic
communication – ISBN 987-81- 318-0734
Figure 6: The categories of ODX 2.2.0

After the calculation, the flashtool sends the key to the For the CCU, the block length is 4080 bytes.
CCU (securityAccess > sendKey), and the CCU compares The TransferData request (36h) contains the flashware
the key with its own value. If the key is correct, the CCU and comes with a block sequence counter that starts with
unlocks and waits for the next diagnostic service request, the value 01h. Since the number of bytes per block is big-
which is the request to transition into the programming ses- ger than the number of bytes that fit in a single CAN data
sion (diagnosticSessionControl > programmingSession). frame, the TransferData service uses segmented data
The LICoS flashtool requires a security access for repro- transfer and is repeated until a block is written. The flash
download sequence is terminated with a RequestTransfer-
Exit request (37h) and a RoutineControl (31h) request to
check the block. The flash download sequence is repeated
until all blocks are transferred. When the flashtool has sent
Figure 7: Excerpt of the CCU 70 S-record the last byte of the flashware, the CCU performs a software
reset (11h) and returns to the UDS default session.
gramming Liebherr ECUs. In this example, the upload of The LICoS Flashtool is created as a C-program on
the current flash memory content is not part of the process. the MVCI D-Server API. It needs about two and a half min-
utes for the reprogramming of the 3 MiB, meaning that
Flash download sequence the performance (actual data rate) is about 20 kbit/s on a
CAN network with 1 Mbit/s bit-rate. The performance of the
The flash download sequence (see Figure 8) starts with flashtool depends on several parameters: Since not all S-
the request (31h) to erase the flash memory. After the flash records contain executable code or data, the performance
memory is erased, the CCU is ready to receive and pro- can be enhanced if the flashtool checks the S-records in
gram the new flashware. To initiate the data transfer, the the pre-processing sequence and then downloads only
flashtool sends a RequestDownload request (34h), which blocks that contain executable code and data.
contains the data parameters dataFormatIdentifier, ad- The performance depends also on the selected CAN
dressAndLenghtFormatIdentifier, memoryAdress, and bit-rate and the block size, as well as on the implementation
memorySize. The dataFormatIdentifier is set to 00h, mean- of the D-PDU API for the connection of the D-Server with
ing that the data is nei- the VCI. Additionally, the ECU needs time to program the
ther compressed nor flashware to the flash memory. This time depends on the
encrypted. The other flash memory technology and firmware that is implemented
parameters contain in- in the ECU.
formation on the flash
memory of the CCU.
The positive re-
sponse to the request
download service (74h) Authors
contains the data pa-
rameter maxNumber Peter Subke, Klaus Hartwig
OfBlockLength, which Softing Automotive Electronics
lets the flashtool know www.softing.com
the number of data
bytes that can be sent Volker Marquart
by each transferData Figure 8: LICoS Flash Liebherr Elektronik
request message. Download Sequence www.liebherr.com

46 CAN Newsletter 3/2015

 s at the
Visit u

d 130
, stan
Hall 2
 Solutions for
CAN

First class solutions for your

CAN and CAN FD based projects
Apply the complete Vector tool chain to increase the efficiency of
your projects:
> Tools for testing, flashing and calibrating ECUs
> Flexible bus network interfaces
> High performance Scope for bit accurate signal analysis
> Easy to configure AUTOSAR basic software
> Worldwide engineering services and trainings

More CAN power: benefit from Vector‘s 25 years of CAN experience

Information and downloads: www.can-solutions.com

ster
C A N FD Po e:
C AN/ der for fre oster
r d_p
now o /canf
r.com
vecto
www.

Vector Informatik GmbH