AUTOSAR Diagnostic Overview

Terms and Definitions

Diagnostic service
information exchange initiated by a client in order to require diagnostic
information from a server and/or to modify its behavior for diagnostic
purposes

Server
function that is part of an electronic control unit and that provides the
diagnostic services

Tester
system that controls functions such as test, inspection, monitoring or
diagnosis of an on-vehicle electronic control unit and which may be
dedicated to a specific type of operator (e.g. a scan tool dedicated to
garage mechanics or a test tool dedicated to assembly plant agents)

Diagnostic data
data that is located in the memory of an electronic control unit which may
be inspected and/or possibly modified by the tester (diagnostic data
includes analogue inputs and outputs, digital inputs and outputs,
intermediate values and various status information)

Architecture Contents of Software Layer

The Debugging module supports

debugging of the AUTOSAR BSW. It
interfaces to ECU internal modules
and to an external host system via
communication .
The Diagnostic Event Manager
is responsible for processing and
storing diagnostic events (errors)
and associated FreezeFrame data.
The module Diagnostic Log and
Trace supports logging and tracing
of applications. It collects user
defined log messages and converts
them into a standardized format.
The Diagnostic Communication
Manager provides a common API
for diagnostic services
The
Function
Inhibition
Manager
is
responsible
for
providing a control mechanism for
software components and the
functionality
The Network layer part of

Why DCM?

The functionality of the DCM module is used by external

diagnostic tools during the development, manufacturing or
service
The DCM module ensures diagnostic data flow and manages
the diagnostic states, especially diagnostic sessions and
security states
The DCM module checks if the diagnostic service request is
supported and if the service may be executed in the current
session according to the diagnostic states.

Overview of the communication between the external

diagnostic tools and the onboard AUTOSAR Application

DCM Overview with AUTOSAR

In the AUTOSAR architecture, the Diagnostic Communication
Manager module is located in a Communication services
(Service Layer).
The Dcm Interfaces with communication modules to transfer
information from an ECU to an off-board Tester and viceversa.
UDS Service
This refers to a UDS Service as defined in ISO14229-1
Note: All UDS Service defined in ISO14229-1 is not
supported by the Dcm module
OBD Service
This refers to an OBD Service as defined in ISO15031-5
Note: All UDS OBD Service as defined in ISO15031-5 is
not supported by the Dcm module

Diagnostics Communication
Manager
The functionality of Dcm module is used by external
diagnostic tools e.g. in the development, manufacturing or
service
Diagnostic services include functions such as test,
inspection, monitoring or diagnosis of on-board vehicle
servers (ECU).
The information transferred might consist of ECU fault
information,
parameter
reporting,
control
routines,
calibration values and other types of data used in performing
ECU diagnostics.
The Dcm module is network independent. All the network
specific functionality (the Specifics of networks like CAN, LIN,
FlexRay or MOST) is handled outside of the Dcm.
The PDU Router (PduR) module provides a networkindependent interface to the DCM module.
The Dcm requests data or functional state from SW-Cs via
port interfaces or from other BSW modules through direct
function calls if any of the data elements or functional states

Unified diagnostic services (UDS) Supported

(R4.0.3)

The DSP provides the following diagnostic UDS services:

o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o

DiagnosticSessionControl (0x10)
ECUReset (0x11)
SecurityAccess (0x27)
CommunicationControl(0x28)
TesterPresent (0x3E)
ControlDTCSetting (0x85)
ResponseOnEvent (0x86)
LinkControl (0x87)
ReadDataByIdentifier (0x22)
ReadMemoryByAddress (0x23)
ReadScalingDataByIdentifier (0x24)
ReadDataByPeriodicIdentifier (0x2A)
DynamicallyDefineDataIdentifier (0x2C)
WriteDataByIdentifier (0x2E)
ClearDiagnosticInformation (0x14)
ReadDTCInformation (0x19)
InputOutputControlByIdentifier (0x2F)
RoutineControl (0x31)
RequestDownload (0x34 hex)
RequestUpload (0x35)
TransferData (0x36 hex)
RequestTransferExit (0x37)

OBD service supported Supported (R4.0.3)

The DSP provides the following diagnostic OBD services:

o Relevant OBD Service Identifier
o Request current powertrain diagnostic data ($01)
o Request current powertrain freeze frame data ($02)
o Request confirmed emission related DTCs ($03)
o Clear/Reset emission related diagnostic information ($04)
o Request monitoring test results for specific monitored
systems ($06)
o Request pending emission related DTCs ($07)
o Request control of on-board system, test or component
($08)
o Request vehicle information and IUMPR ($09)
o Request emission-related DTCs with permanent status
($0A)

Diagnostics Event Manager

The Diagnostic Event Manager (Dem) handles and stores the
events detected by diagnostic monitors in both Software
Components (SW-Cs) and Basic software (BSW) modules
The stored event information is available via an interface to
other BSW modules or SW-Cs
The Dem module uses the EventId to manage the status of
the Diagnostic Event of a system and performs the
required actions for individual test results
E.g. stores the freeze frame(If qualified as Failed)
The Dem module shall represent each Diagnostic Event by
an EventId and the related EventName.
All monitors and BSW modules use the EventId as a symbolic
EventName.
The EventId and the related EventName shall be unique per
Dem module represented by the ECU configuration

Diagnostic Log and Trace

Each application software component (SW-C) can report errors to the Dlt
Collects log messages and converts them into a standardized format. The
Dlt forwards the data to the Dcm or a CDD which uses a serial interface for
example
Logging
logging of errors, warnings and info messages from AUTOSAR SW-Cs,
providing a standardized AUTOSAR interface
gathering all log and trace messages from all AUTOSAR SW-Cs in a
centralized AUTOSAR service component (Dlt) in the BSW
logging of messages from Det and
logging of messages from Dem
Tracing
RTE activities
Control
individual log and trace messages can be enabled/disabled and
Log levels can be controlled individually by back channel
Generic
Dlt is available during development and production phase
access over standard diagnosis or platform specific test interface is
possible and

Diagnostic Log and Trace

Debugging Module
To support a user (system integrator or BSW developer) during
development, in case the basic software does not behave as
expected
Collects as much information as possible about the runtime
behavior of the systems without halting the processor
Data is transmitted to an external host system via communication,
to enable the user to identify the source of a problem
An internal buffer is provided to decouple data collection from
Main tasks of the Debugging Module are to
data transmission
Collect and store data for tracing purposes
Collect and immediately transmit data to host
Modify data in target memory on host request
Transmit stored data to host
Accept commands to change the behavior of the Debugging
Module

 Tracing Principles Debugging Module use cases

Tracing means collecting information from running software. To
perform tracing, the software is not halted
Tracing of variables
Cyclically
on event
Tracing of functions
In order to implement tracing of functions, the code has to be
instrumented with calls to Collect Function Tracing Information
(function entry) API when the function is entered and calls to Collect
Function Tracing Information (function exit) API before leaving the
function
Tracing of SW-C
The debugging module offers functions to the RTE to trace information
from the following RTE events
signal transmission
signal reception
COM callback
start runnable

AUTOSAR DEM Overview

DEM Diagnostics Event Manager

The service component Diagnostic Event Manager (Dem) is
responsible for processing and storing diagnostic events (errors)
and its associated data
The Dem offers interfaces to the application layer and to other
BSW modules to make the stored event information available
Dem provides fault information to the Dcm

Diagnostics Event
A Diagnostic Event defines the atomic unit that can be handled
by the Dem module
The status of a Diagnostic Event represents the result of a
monitor
The Dem receives the result of a monitor from SW-C via the RTE or
other BSW modules
The Dem module uses the EventId to manage the status of the
Diagnostic Event of a system and performs the required actions
for individual test results

Elements of Diagnostics Event

Event priority
It is defined as a ranking of events based upon level of
importance
It is used to determine which fault entries may be removed
from the event memory in the case of the number of stored
events exceeds the maximum number of memory entries
A priority value of 1 is the highest priority. Larger priority value
shall define lower importance
Event occurrence
The Dem module provides an occurrence counter per event
memory entry
The Dem module increments the occurrence counter by one if
the related event is already stored in the event memory and
the UDS DTC status bit 0 (TestFailed) changes from 0 to 1
If the configuration parameter
DemOccurrenceCounterProcessing (in container DemGeneral)
is DEM_PROCESS_OCCCTR_CDTC, the Dem module only
increments the occurrence counter if the fault confirmation has
been successfully finished

Elements of Diagnostics Event

Event kind
There are two different types of events:

BSW-related events (reported via C-API

Dem_ReportErrorStatus)

SW-C-related events (reported via RTE operation

SetEventStatus)
Event significance
There are two different significance levels of events:

fault: classifies a failure, which relates to the

component/ECU itself
(and requires for example a
repair action)

occurrence: classifies an issue, which indicates

additional information
concerning insufficient system
behavior (and relates for example
to a condition out of
the ECUs control)
Event destination
The configuration parameter DemEventDestination

Diagostic monitor

Diagostic monitor
A diagnostic monitor is a routine entity determining the proper
functionality of a component
The monitoring function identifies a specific fault type (e.g.
short to ground, open load, etc.) for a monitoring path
A monitoring path represents the physical system or a circuit,
that is being monitored (e.g. sensor input). Each monitoring
path is associated to exactly one diagnostic event.
If the monitor debounces on its own, the reporting API is called
only after a qualified result (passed or failed) is available
If the monitor uses Dem-internal debouncing mechanism, the
reporting API is called whenever the code with the functional
check is executed

DTC & DTC groups

Diagnostic trouble code
There are two different kinds of DTCs:

non OBD-relevant DTCs (UDS DTCs)

OBD-relevant DTCs
DTC groups
The following DTC groups are provided:
emission-related DTC group (optional, fixed value =
0x000000)
powertrain DTC group (optional, configurable value)
chassis DTC group (optional, configurable value)
body DTC group (optional, configurable value)
network communication DTC group (optional, configurable
value)
further user-defined DTC groups (optional, configurable
value)
all DTCs DTC group (mandatory, fixed value = 0xFFFFFF)

Operation cycle management

The Dem module uses different operation cycles
The cycles could either be provided by other BSW modules and
SW-C or generated by the Dem module itself
Examples of operation cycles are:
- driving cycle
- engine warm up cycle
- ignition on/off cycle
- power up/power down cycle
- operation active/passive cycle
- accumulated operating time
The operation cycle management of the Dem module uses the
reported state (DEM_CYCLE_STATE_START /
DEM_CYCLE_STATE_END) of the API Dem_SetOperationCycleState
(refer to chapter 8.3.3.6) to set the Dem specific operation cycle
state (started / ended)

Event status management

The Event Status Management is the Dems ability to record and
retain events, event status and associated data
The Dem module provides the capability to report the status of an
event through the API Dem_SetEventStatus allowing a
diagnostic monitor to inform the Dem about the result of the
internal diagnostic test
The Dem module provides the capability to reset the failed status
of an event without reporting a passed result through the API
Dem_ResetEventStatus
The Dem module provides the capability to retrieve the current
UDS DTC status byte of a specific event through the API
Dem_GetEventStatus
The Dem module provides the current event failed status through
the API Dem_GetEventFailed
The Dem module provides the current event tested status through
the API Dem_GetEventTested

Status bit update

In case a qualified diagnostic event (passed / failed) is reported to the
Dem module, the Dem performs the event status transition
immediately for the bits being relevant for fault reactions
Bit 0 TestFailed
Bit 1 TestFailedThisOperationCycle
Bit 4 TestNotCompletedSinceLastClear
Bit 5 TestFailedSinceLastClear
Bit 6 TestNotCompletedThisOperationCycle
Notification of status bit changes
The Dem module triggers the event-specific callback-function
EvenStatusChanged on each event status change
The configuration container
DemCallbackEventStatusChanged is used to specify one or
more ports/c-callbacks per event

Debouncing of diagnostic events

If the Dem module is configured to implement the debounce algorithm
for a specific event, one of the following debounce algorithms are to
be performed Dem-internally
Counter based debounce algorithm
Time based debounce algorithm
Further specific debounce algorithms
Monitor internal debounce algorithm
The Dem module supports the event-specific configuration of
debounce algorithms by using the configuration container
DemDebounceAlgorithmClass

Counter based debounce algorithm

The Dem module calculates the fault detection counter (-128 +127
according to UDS) based on the value and range of the internal
debounce counter to map the internal counter values linearly to the
external values
DemDebounceCounterFailedThreshold defines the event-specific limit
indicating the failed status (active)
DemDebounceCounterPassedThreshold defines the event-specific
limit indicating the passed status (passive)
The Dem module increments the internal debounce counter with its
configured step-size (DemDebounceCounterIncrementStepSize), when
the monitor reports DEM_EVENT_STATUS_PREFAILED
The Dem module decrements the internal debounce counter with its
configured step-size (DemDebounceCounterDecrementStepSize),
when the monitor reports DEM_EVENT_STATUS_PREPASSED
If the monitor reports DEM_EVENT_STATUS_FAILED, the Dem module
sets the internal debounce counter value to its configured threshold
being the failed criteria
If the monitor reports DEM_EVENT_STATUS_PASSED, the Dem module
sets the internal debounce counter value to its configured threshold
being the passed criteria

Counter based debounce algorithm contd.

The Dem module provides the configuration parameter

DemDebounceCounterJumpDown for activating or deactivating the
jump down behavior
If the jump down behavior is active, the Dem module provides the
configuration parameter DemDebounceCounterJumpDownValue
defining the new internal debounce counter init value if the counting
direction changes from incrementing to decrementing
The Dem module provides the configuration parameter
DemDebounceCounterJumpUp for activating or deactivating the jump
up behavior
If the jump up behavior is active, the Dem module provides the
configuration parameter DemDebounceCounterJumpUpValue defining
the new internal debounce counter init value if the counting direction
changes from decrementing to incrementing

Counter based debounce algorithm Example