The Standard Mix does it:

Diagnostics with AUTOSAR and ODX – Part 1: Diagnostics with AUTOSAR

AUTOSAR is the future-oriented reference architecture for ECU software. Clearly specified interfaces, standardized be-
havior and XML-based data formats are the key features of this standard. In AUTOSAR, diagnostics is handled in the
modules DCM (communications) and DEM (fault memory). This article first addresses diagnostics in AUTOSAR and re-
lated data formats. Description data in ODX format (Open Diagnostic Data Exchange) represents an alternative to
configuring the diagnostic software. Part 2 will address the topic of “ODX in the AUTOSAR development process”.

Standardization is very much the trend in the development >>Standardized data exchange formats between OEM and
of automotive electronics. The use of open architectures suppliers
and configurable components are intended to let develop- >>Definition of a harmonized methodology for developing
ers focus more on the innovative and differentiating as- software
pects of the development process. In addition, standard- >>Support of model-based functional development
ization is intended to be a central measure that contributes >>Scalability over all ECU and vehicle classes
towards reducing costs. In the past, automotive ECU soft- >>Considers safety requirements per ISO 26262
ware architectures were not standardized. For the supplier,
this resulted in different, OEM-specific software architec- Today, AUTOSAR is the reference architecture for ECU
tures that required different development processes, de- software. The first production launches with complete AU-
velopment tools and data exchange formats. AUTOSAR TOSAR software will occur in the near future. The number
(AUTomotive Open System ARchitecture) has the stated of development projects utilizing AUTOSAR methodology is
goal of standardizing a common, open automotive soft- continually growing.
ware architecture. The primary goals of the AUTOSAR ar- The AUTOSAR Consortium is currently working on versions
chitecture are: 3.2 and 4.x. Versions 2.x, 3.x and 4.0, which were released
>>Hardware abstraction prior to this, have already been used as a basis for imple-
>>Clearly specified interfaces menting vehicle projects. Today, most vehicle producers
>>Standardized behavior of the basic software work to versions 3.x.

1
Functional orientation is increasingly gaining in significance implements the Virtual Function Bus for a specific ECU.
in electronic development. AUTOSAR standardizes the de- The basic software is developed as a component kit and is
scription of individual component or vehicle functions and commercially available (off-the-shelf software). It contains
the description of the overall system in what is known as fundamental system functions and abstracts the function-
the System Configuration Description. The methodology al software from the hardware. It is subdivided into three
for distributing vehicle functions to ECUs is also standard- areas (Figure 2):
ized. As a result, developed functions can be reused in other >>The Service Layer provides basic services for the func-
vehicle projects without changes. tional software and other basic software modules.
The example in Figure 1 illustrates this: The Lighting vehicle >>The ECU Abstraction Layer abstracts higher layers from
function from the Function Library is subdivided into three the ECU hardware
subfunctions. In vehicle A, the subfunctions are distributed >>The Microcontroller Abstraction Layer abstracts higher
to two network ECUs, while in vehicle B they are distributed layers from the specific microcontroller device
unchanged to three ECUs. The communication between
the subfunctions is defined in the System Configuration The ECU Configuration Description is used to configure the
Description. basic software and the RTE. Initially, this configuration is
In AUTOSAR, there is an ECU Extract of the System Con- generated from the ECU Extract of the System Configura-
figuration for each ECU that covers the system content tion Description (e.g. communication over the network).
relevant to the ECU – and often also relevant to a supplier. The ECU Configuration Description plays a central role for
The elementary components of AUTOSAR architecture for the behavior of the entire ECU software and is extended
ECU software are: and adapted, step by step, over the course of further devel-
>>Functional software (SWC) opment.
>>Run-Time environment (RTE)
>>Basic software (BSW) Diagnostics with AUTOSAR
The diagnostic software in AUTOSAR consists of three
The high level of reusability of the functional software is modules: DCM, DEM and FIM. The DCM (Diagnostic Com-
due to the abstraction of communication by the Virtual munication Manager) implements the diagnostic commu-
Function Bus (VFB). The application can be developed and nication per ISO 14229-1 (UDS) and SAE J1979 (OBDII). All
tested without knowledge of the underlying communica- diagnostic requests are first preprocessed by the DCM.
tion mechanisms. It does not matter here whether commu- One of the tasks of the DCM is comprehensive handling of
nication occurs within the ECU or over a network (CAN, invalid diagnostic requests. The DCM can already fully pro-
FlexRay, etc.). The Run-Time-Environment (RTE) serves as cess a majority of valid requests; it routes other requests to
the runtime environment for the functional software, and it the functional software. Each AUTOSAR release has in-

Vehicle A Vehicle B
Hardware
Topology

Functional Library Software

Lighting Configuration

Seat Heating
Air Conditioning

Distributed
System

ECU Extract
of System Figure 1:
Description Functional distribution in
AUTOSAR

2
 Application
AUTOSAR Runtime Environment

System Memory Comm.

Services Services Services I/O
Signal
Onboard Memory Comm. Interface Complex
Device Hardware Hardware Device
Abstraction Abstraction Abstraction Drivers

Micro-
Memory Comm. I/O
controller
Drivers Drivers Drivers
Drivers

Microcontroller
Microcontroller ECU Abstraction Service
Abstraction Layer Layer Layer Fig­ure 2: Structure of the basic software (BSW)

creased the functional range of the DCM, while continually >>Organize snapshot data (freeze frame)
decreasing the remaining diagnostic content of the func- >>Administer extended data records
tional software. Handling of a DID (Figure 3) illustrates this >>Provide for unlearning of errors
development. Up to Version 3, signal structures had to be >>Provide an interface for error readout for the DCM
resolved in the functional software. In Version 4, this task
can also be handled by the DCM. A standardized interface and various debounce algorithms
The DCM is configured based on a ECU Configuration De- for diagnostic monitors (error path) enable uniform and
scription. This includes the service identifiers, subfunctions, cross-project development of the functional software. One
data identifiers (with associated signal structure) and rou- or more error paths can be mapped to a diagnostic trouble
tine identifiers (with parameter lists). In addition, execu- code (DTC). The DEM is also configured from the ECU Con-
tion of diagnostic requests can be made dependent on the figuration Description. It contains information related to
current ECU state (session and security level). error paths, DTC numbers and the structure of extended
The DEM (Diagnostic Event Manager) implements an error error data (snapshot and extended data records).
memory. Up to (and including) AUTOSAR Version 3.x, the The FIM (Function Inhibition Manger) makes it possible to
DEM is only specified as a facade, because details of error inhibit the execution of certain functions in case of active
memory behavior are OEM-specific. Since Version 4, the errors, start substitute functions and suppress secondary
goal has been to standardize an OEM-independent error errors. The FIM is also configured from the ECU Configura-
memory, so that its behavior can be defined in AUTOSAR. tion Description.
The DEM has the following primary tasks:
>>Administer the DTC status bit Basic Software Modules for Diagnostics with AUTOSAR
>>Organize error storage, including NVRAM Vector’s MICROSAR product line provides an AUTOSAR
solution for ECU software consisting of the RTE and basic
software modules that cover the entire scope of the
­AUTOSAR standard. Each AUTOSAR BSW module is as-
SID DID Data
signed to a MICROSAR package. The MICROSAR DIAG
package is specially available for diagnostics. It contains
Request 22 FF EE the three BSW modules DCM, DEM and FIM from the
­AUTOSAR architecture. MICROSAR DIAG as the diagnostic
Response 62 FF EE AA BB CC software provides vehicle projects with an AUTOSAR-­
compatible implementation of the UDS protocol ISO 14229-
AUTOSAR 2.1 3.x 4.x 1:2006.
Version Note: Part 2 “ODX in the AUTOSAR development process”
is also available for download at www.vector.com/down-
Fig­ure 3: DCM in different AUTOSAR versions
loads/.

3
 The Standard Mix does it:

Translation of a German publication in Hanser Automotive,

10/2011

Literature:
[1] AUTOSAR specifications: www.autosar.org
[2] Pascale Morizur, Matthias Wernicke, Justus Maier:
Neue Wege zur Steuergeräte-Software Teil 1, Elektronik
­automotive 11.2009
[3] Pascale Morizur, Matthias Wernicke, Justus Maier:
Neue Wege zur Steuergeräte-Software Teil 2, Elektronik
­automotive 12.2009
[4] ISO 14229: Road vehicles – Unified diagnostic services
(UDS)
[5] ISO 26262: Road vehicles – Functional safety
[6] ISO 22901: Road vehicles – Open diagnostic data
­exchange (ODX)
[7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetz­
liche On-Board-Diagnose und ODX, Diagnose in mecha-
tronischen Fahrzeugsystemen III S. 44 ff., Expert-Verlag
2010

Dr. Klaus Beiter

leads a development team for the Automotive Diagnostics
­product line at the company Vector Informatik GmbH in
­Stuttgart. He is a member of the ASAM/ISO ODX working
group.

Oliver Garnatz
is employed at Vector Informatik GmbH as a product manager in
the Embedded Software Components area. He is a member of
the Automotive Diagnostics area of ISO and the AUTOSAR area.

Christoph Rätz
is the Director of the Diagnostics product line at the company
Vector Informatik GmbH in Stuttgart.