Requirements on Diagnostics

AUTOSAR FO R22-11

Document Title Requirements on Diagnostics

Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 4

Document Status published

Part of AUTOSAR Standard Foundation
Part of Standard Release R22-11

Document Change History

Date Release Changed by Description
• New requirements for CP and AP
AUTOSAR • Correction of requirement
2022-11-24 R22-11 Release assignment to CP and AP
Management • Additional requirements for SOVD
support
• New requirements for CP and AP
AUTOSAR • Correction of requirement
2021-11-25 R21-11 Release assignment to CP and AP
Management • Additional requirement for SW
Cluster support in AUTOSAR Classic
AUTOSAR • New requirements for CP and AP
2020-11-30 R20-11 Release • Correction of requirement
Management assignment to CP and AP

AUTOSAR • Renamed to RS Diagnostics

2019-11-28 R19-11 Release • New requirements for CP and AP
Management • Changed Document Status from
Final to published
AUTOSAR
2019-03-29 1.5.1 Release • No content changes
Management
AUTOSAR
2018-10-31 1.5.0 Release • New requirements for CP and AP
Management • Structural optimization of document
AUTOSAR
2018-03-29 1.4.0 Release • New requirements for CP and AP
Management • Structural optimization of document

1 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

AUTOSAR
2017-12-08 1.3.0 Release • Minor corrections
Management • Update of requirements tracing

AUTOSAR • Restructured document

2017-10-27 1.2.0 Release • New requirments for CP and AP
Management • Common requirements for CP and
AP

AUTOSAR • Merge and alignment with AP

2017-03-31 1.1.0 Release requirements
Management • Restructured chapter 4
• Removed reference to HIS
• –Migration of document to standard
"Foundation"–
• Additional requirements for
AUTOSAR ISO14229-1 conformance
2016-11-30 1.0.0 Release • Parallel access for DEM
Management • Parallel processing of OBD and UDS
services
• Independent fault memory access for
virtual ECUs

AUTOSAR • Clarification of bootloader interaction

2015-07-31 4.2.2 Release • Interfaces for DCM communication
Management via PDU router
• Rework of document structure
• Support of WWH-OBD (Major
change)
AUTOSAR • Support of UDS service $38
2014-10-31 4.2.1 Release (”RequestFileTransfer”), (Change)
Management • Added new requirements for runtime
errors and transient errors (Change)
• Aging of events (Change)

AUTOSAR • New requirement for processing a

2014-03-31 4.1.3 Release new request in DEM
Management • New requirement for event
management mechanisms in DEM

2 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

• OBD-specific configuration
capabilities in DCM and DEM
• Event de-bouncing in DEM
• Freeze Frame and Extended Data
AUTOSAR Record handling in DEM
2013-03-15 4.1.1 Release • Support of SAE J1939
Management • Link Requiriement with BSW Feature
Document
• Updating format of requirements
according to
TPS_StandardizationTemplate
AUTOSAR • Clarification of DET functionality
2011-12-22 4.0.3 Release • Formal Rework for Requirements
Management Tracing
AUTOSAR
2011-04-15 4.0.2 Release • Clarification of DET functionality
Management (remove BSW04088)

• Document structure reworked and

extended
• Improvement of DEM behavior
AUTOSAR description
2010-09-30 3.1.5 Release • Introduce the approach for functional
Management diagnostics of SW-Cs
• Added requirements for further
diagnostic modules (DLT/DET)
• Legal disclaimer revised
• Remove requirement BSW04062
AUTOSAR • Added requirement
2008-08-13 3.1.1 Release [SRS_Diag_04082] for OBDII
Management support
• Legal disclaimer revised
AUTOSAR • Document meta information
2007-12-21 3.0.1 Release extended
Management • Small layout adaptations made
AUTOSAR
2007-01-24 2.1.15 Release • ”Advice for users” revised
Management • ”Revision Information” added
AUTOSAR
2006-11-28 2.1 Release • Legal Disclaimer revised
Management

3 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

AUTOSAR
2006-05-16 2.0 Release • Minor formal changes
Management
AUTOSAR
2005-05-31 1.0 Release • Initial Release
Management

4 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

Disclaimer

This work (specification and/or software implementation) and the material contained in
it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the work.
The material contained in this work is protected by copyright and other types of intel-
lectual property rights. The commercial exploitation of the material contained in this
work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the work
may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.

5 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

Contents
1 Scope of the Document 12

2 Acronyms and Abbreviations 13

3 Conventions to be used 14

4 Requirements Specification 15
4.1 Common Diagnostic requirements for Classic and Adaptive Platform . 15
[RS_Diag_04200] Support event combination . . . . . . . . . . . . . . . 15
[RS_Diag_04150] Support the primary fault memory defined by ISO
14229-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
[RS_Diag_04214] Support the user defined fault memories defined by
ISO 14229-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
[RS_Diag_04068] The diagnostic in AUTOSAR shall support event spe-
cific debounce counters to improve signal quality internally
(According to ISO 14229-1 Appendix D) . . . . . . . . . . . . 16
[RS_Diag_04225] The diagnostic in AUTOSAR shall support event spe-
cific time base debounce counters . . . . . . . . . . . . . . . 16
[RS_Diag_04115] The optional parameter DTCSettingControlOption-
Record as part of UDS service ControlDTCSetting shall be
limited to GroupOfDTC . . . . . . . . . . . . . . . . . . . . . 17
[RS_Diag_04064] Provide configurable buffer sizes for storage of the
events, status information and environmental data . . . . . . 17
[RS_Diag_04172] Inform external service processors about outcome of
the final response . . . . . . . . . . . . . . . . . . . . . . . . 17
[RS_Diag_04127] Configurable record numbers and trigger options for
DTCSnapshotRecords and DTCExtendedDataRecords . . . 18
[RS_Diag_04177] Custom diagnostic services . . . . . . . . . . . . . . 18
[RS_Diag_04059] Configuration of timing parameters . . . . . . . . . . 18
[RS_Diag_04033] Support the upload/download services for read-
ing/writing data in an ECU in an extended and manufacturer
specific diagnostic session . . . . . . . . . . . . . . . . . . . 19
[RS_Diag_04020] Suppress responses to diagnostic tool requests . . . 19
[RS_Diag_04119] Handle the execution of diagnostic services according
to the assigned diagnostic session . . . . . . . . . . . . . . . 19
[RS_Diag_04016] Support ”Busy handling” by sending a negative re-
sponse 0x78 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
[RS_Diag_04006] Manage session handling . . . . . . . . . . . . . . . . 20
[RS_Diag_04005] Manage Security Access level handling . . . . . . . . 21
[RS_Diag_04135] Support UDS service $38 (RequestFileTransfer) . . . 21
[RS_Diag_04098] Interact with standard bootloader . . . . . . . . . . . 21
[RS_Diag_04159] Control of DTC storage . . . . . . . . . . . . . . . . . 22
[RS_Diag_04157] Reporting of DTCs and related data . . . . . . . . . . 22
[RS_Diag_04156] Support DTCFunctionalUnit . . . . . . . . . . . . . . 22

6 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04077] Uses standard mechanisms provided by persistency

modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
[RS_Diag_04131] Consistent event management mechanisms . . . . . 23
[RS_Diag_04117] Configurable behavior for DTC deletion . . . . . . . . 23
[RS_Diag_04107] Provide defensive behavior . . . . . . . . . . . . . . . 23
[RS_Diag_04105] Event memory management . . . . . . . . . . . . . . 24
[RS_Diag_04091] Notification about valid freeze frame data to applications 24
[RS_Diag_04151] Event status handling . . . . . . . . . . . . . . . . . . 25
[RS_Diag_04071] Process events according to their defined importance
like priority and/or severity . . . . . . . . . . . . . . . . . . . 25
[RS_Diag_04125] Event debounce counter shall be configurable . . . . 25
[RS_Diag_04136] Configurable ”confirmed” threshold . . . . . . . . . . 26
[RS_Diag_04140] Aging for UDS status bits ”confirmedDTC” and ”test-
FailedSinceLastClear” . . . . . . . . . . . . . . . . . . . . . . 26
[RS_Diag_04232] Access rights in client certificates . . . . . . . . . . . 26
[RS_Diag_04233] Access granularity of diagnostic services . . . . . . . 27
[RS_Diag_04234] Binary compatibility of white list for individual access 28
[RS_Diag_04235] Client certificate validity . . . . . . . . . . . . . . . . . 28
[RS_Diag_04236] Client certificate target identification . . . . . . . . . . 28
[RS_Diag_04237] Client certificate evaluation . . . . . . . . . . . . . . . 29
[RS_Diag_04238] Logging certificate evaluation . . . . . . . . . . . . . 29
[RS_Diag_04239] Diagnostic services in deauthenticated state . . . . . 29
[RS_Diag_04240] Application based authentication . . . . . . . . . . . . 30
[RS_Diag_04133] Aging for event memory entries . . . . . . . . . . . . 30
[RS_Diag_04063] Process a dedicated event identifier for each moni-
toring path to support an autonomous handling of different
events/faults . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
[RS_Diag_04148] Provide capabilities to inform applications about diag-
nostic data changes . . . . . . . . . . . . . . . . . . . . . . . 31
[RS_Diag_04097] Decentralized and modular diagnostic configuration in
applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
[RS_Diag_04067] Provide the diagnostic status information according to
ISO 14229-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
[RS_Diag_04179] Provide interfaces for monitoring application. . . . . . 32
[RS_Diag_04178] Support operation cycles according to ISO 14229-1 . 33
[RS_Diag_04201] Support a configuration to assign specific events to a
customer specific DTC . . . . . . . . . . . . . . . . . . . . . 33
[RS_Diag_04180] Process all UDS Services related to diagnostic fault
memory of ISO 14229-1 internally . . . . . . . . . . . . . . . 33
[RS_Diag_04182] Provide an application interface to change operation
cycles states . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
[RS_Diag_04183] Notify interested parties about event status changes . 34
[RS_Diag_04185] Notify applications about the clearing of an event . . 34
[RS_Diag_04186] Notify applications about the start or restart of an op-
eration cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
[RS_Diag_04204] Provide the current status of each warning indicator. . 35

7 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04205] Support of SnapshotRecords . . . . . . . . . . . . . . 35

[RS_Diag_04206] Support of ExtendedDataRecords . . . . . . . . . . . 36
[RS_Diag_04189] Support a fine grained configuration for Snap-
shotRecords and ExtendedDataRecords . . . . . . . . . . . 36
[RS_Diag_04190] Usage of internal data elements in SnapshotRecords
and ExtendedDataRecords . . . . . . . . . . . . . . . . . . . 36
[RS_Diag_04192] Provide the ability to handle event specific enable
conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
[RS_Diag_04219] Provide the ability to handle event specific storage
conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
[RS_Diag_04194] ClearDTC shall be accessible for applications . . . . 37
[RS_Diag_04195] Chronological reporting order of the DTCs located in
the configured event memory . . . . . . . . . . . . . . . . . . 38
[RS_Diag_04211] Persistent storage of DTC status and environmental
data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
[RS_Diag_04220] Support DTCs suppression . . . . . . . . . . . . . . . 38
[RS_Diag_04196] UDS Service handling for all diagnostic services de-
fined in ISO 14229-2 . . . . . . . . . . . . . . . . . . . . . . . 38
[RS_Diag_04203] Common checks on all supported UDS Services Re-
quests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
[RS_Diag_04226] Diagnostic session check . . . . . . . . . . . . . . . . 39
[RS_Diag_04227] Common check for Security Access . . . . . . . . . . 40
[RS_Diag_04228] Common check for Message lengths . . . . . . . . . 40
[RS_Diag_04197] Clearing the user defined fault memory . . . . . . . . 40
[RS_Diag_04198] Process all UDS Services related to session and se-
curity management of ISO 14229 internally . . . . . . . . . . 41
[RS_Diag_04199] Provide a configurable UDS service execution mech-
anism at runtime to decide if a UDS request shall be pro-
cessed or not . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
[RS_Diag_04208] Inform the application about diagnostic session and
diagnostic security level changes on each tester connection. 41
[RS_Diag_04218] Support of UDS service 0x2F InputOutputControlByI-
Dentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
[RS_Diag_04222] Independence of clearing DTC status and system
degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
[RS_Diag_04224] Support the UDS service 0x31 (RoutineControl) ac-
cording to ISO 14229-1 . . . . . . . . . . . . . . . . . . . . . 42
[RS_Diag_04242] The DoIP module shall support Vehicle Internal Testers. 43
[RS_Diag_04147] Communication with the transport layers to receive
and send diagnostic data . . . . . . . . . . . . . . . . . . . . 43
[RS_Diag_04244] Support sub-function 0x04 of UDS service 0x19. . . . 43
[RS_Diag_04245] Support sub-function 0x06 of UDS service 0x19. . . . 44
[RS_Diag_04058] Ability to access different event memories . . . . . . 44
[RS_Diag_04160] ResponseOnEvent according to ISO 14229-1 . . . . 44
[RS_Diag_04109] Provide an interface to retrieve the number of event
memory entries . . . . . . . . . . . . . . . . . . . . . . . . . 44

8 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04246] Support of UDS service DynamicallyDefineDataIden-

tifier (0x2C) with subfunction 0x01 (defineByIdentifier) . . . . 45
[RS_Diag_04215] Support of UDS service ReadDataByPeriodicIdenti-
fier (0x2A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[RS_Diag_04248] Support of session control service . . . . . . . . . . . 46
[RS_Diag_04249] Support of session layer service . . . . . . . . . . . . 46
[RS_Diag_04093] Memory overflow indication . . . . . . . . . . . . . . . 46
[RS_Diag_04118] Optionally support event displacement . . . . . . . . 47
[RS_Diag_04120] Support a predefined AddressAndLengthFormatIden-
tifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
[RS_Diag_04124] Store the current debounce counter value nonvolatile
to over a powerdown cycle . . . . . . . . . . . . . . . . . . . 47
4.2 Diagnostic requirements for the Classic Platform . . . . . . . . . . . . 48
4.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . 48
[RS_Diag_04112] The DEM module shall support DTCs according
to SAE J1939 . . . . . . . . . . . . . . . . . . . . . . 48
[RS_Diag_04139] Support subfunction 0x42 of UDS service 0x19 48
[RS_Diag_04129] Provide OBD-specific configuration capabilities . 49
[RS_Diag_04163] Parallel OBD and UDS processing . . . . . . . . 49
[RS_Diag_04161] Provide support for the ASMIP algorithm . . . . 49
[RS_Diag_04230] Support of UDS service 0x29 (Authentication) . 50
4.2.2 Fault Memory Management . . . . . . . . . . . . . . . . . . . 50
[RS_Diag_04002] The Diagnostic event (fault) management shall
be established as Basic SW Module . . . . . . . . . 50
[RS_Diag_04057] Classification of events for series production,
OBD and expert usage . . . . . . . . . . . . . . . . . 51
[RS_Diag_04123] Harmonized Driving//WarmUp cycles . . . . . . 51
[RS_Diag_04126] Configurable suppression of events . . . . . . . 51
[RS_Diag_04110] SAE J1939 lamp status . . . . . . . . . . . . . . 52
[RS_Diag_04111] SAE J1939 Expanded-FreezeFrame . . . . . . . 52
[RS_Diag_04113] Support a set of SAE J1939 DM-messages . . . 53
[RS_Diag_04241] Support for unsupported SAE J1939 DM-
messages . . . . . . . . . . . . . . . . . . . . . . . . 54
[RS_Diag_04137] Definition of replacement failure . . . . . . . . . 54
[RS_Diag_04155] Notify applications and BSW modules about up-
dates of event related data . . . . . . . . . . . . . . . 54
[RS_Diag_04217] Adding the Lamp status pertinent to a specific
Fault Event/DTC available as DemInternalDataClass
shall be codified in the same format of DM31 . . . . 55
[RS_Diag_04165] Triggering of multiple events upon a master
event is reported . . . . . . . . . . . . . . . . . . . . 55
[RS_Diag_04031] Notify the Function Inhibition Manager (FIM)
upon changes of the event status in order to process
them according to the SW components dependencies 55

9 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04221] In-Use-Monitor Performance Ratio indicates

how often the OBD system monitors particular com-
ponents, compared to the amount of the vehicle op-
eration . . . . . . . . . . . . . . . . . . . . . . . . . . 56
[RS_Diag_04223] Support Snapshot Records data pre-storage . . 56
[RS_Diag_04250] Support subfunction 0x1A and 0x56 of UDS ser-
vice 0x19 . . . . . . . . . . . . . . . . . . . . . . . . 56
[RS_Diag_04252] Support of SAE J1979-2 . . . . . . . . . . . . . 57
[RS_Diag_04253] Support separated DTCs for UDS and OBD
based on J1979-2 . . . . . . . . . . . . . . . . . . . 57
[RS_Diag_04254] Independent CP Software Cluster development 58
[RS_Diag_04255] Support of nested data elements for the DID . . 58
4.2.2.1 DTC and event-related data . . . . . . . . . . . . . . 59
[RS_Diag_04162] Parallel fault memory access . . . . . . 59
[RS_Diag_04164] Independent event memories for multi-
ple diagnostic server instances (virtual ECUs) 59
4.2.3 Diagnostic Communication . . . . . . . . . . . . . . . . . . . 60
[RS_Diag_04021] Handling of different diagnostic sessions in parallel 60
[RS_Diag_04032] Different diagnostic addresses shall be sup-
ported by multiple (physical) channels . . . . . . . . 60
[RS_Diag_04024] Access and handle specific data elements and
data element groups if requested by an external scan
tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
[RS_Diag_04019] Provide confirmation after transmit diagnostic re-
sponses to the application . . . . . . . . . . . . . . . 61
[RS_Diag_04121] Provide the handling of service DynamicallyDe-
fineDataIdentifier according to ISO 14229-1 . . . . . 61
[RS_Diag_04153] Support generic connections . . . . . . . . . . . 61
[RS_Diag_04011] Provide diagnostic state information to applica-
tions . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
[RS_Diag_04003] Network independent design . . . . . . . . . . . 62
[RS_Diag_04243] Update of constant parameters through diagnos-
tics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
[RS_Diag_04247] Support of UDS service DynamicallyDefine-
DataIdentifier (0x2C) with subfunction 0x02 (de-
fineByMemoryAddress) . . . . . . . . . . . . . . . . 63
[RS_Diag_04015] Timing handling according to ISO14229-2 . . . 63
4.2.4 Function Inhibition Manager (FIM) . . . . . . . . . . . . . . . 64
4.3 Diagnostic requirements for the Adaptive Platform . . . . . . . . . . . 64
[RS_Diag_04166] Several tester conversations in parallel with assigned
priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
[RS_Diag_04209] Pseudo parallel client interaction according to ISO . . 64
[RS_Diag_04167] Conversation preemption/abortion . . . . . . . . . . . 64
[RS_Diag_04168] Adding of user-defined transport layers . . . . . . . . 65
[RS_Diag_04169] Provide an interface for external UDS service proces-
sors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

10 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04170] Provide connection specific meta information to ex-

ternal service processors . . . . . . . . . . . . . . . . . . . . 66
[RS_Diag_04171] Synchronous and asynchronous interaction with ex-
ternal service processors . . . . . . . . . . . . . . . . . . . . 66
[RS_Diag_04173] Different signature types, when delegating processing
of UDS service to the application . . . . . . . . . . . . . . . . 67
[RS_Diag_04174] Provide SA and TA to external service processors . . 67
[RS_Diag_04216] Support for multiple Diagnostic Server Instances . . . 67
[RS_Diag_04251] Support of UDS service 0x29 (Authentication) . . . . 68
[RS_Diag_04256] Support of SOVD . . . . . . . . . . . . . . . . . . . . 68
[RS_Diag_04257] Capability Description . . . . . . . . . . . . . . . . . . 68
[RS_Diag_04258] Discovering of Entities and Resources . . . . . . . . 68
[RS_Diag_04259] Fault Memory Access . . . . . . . . . . . . . . . . . . 69
[RS_Diag_04260] Read / Write Access . . . . . . . . . . . . . . . . . . 69
[RS_Diag_04261] Configuration Access . . . . . . . . . . . . . . . . . . 69
[RS_Diag_04262] Control of Operations . . . . . . . . . . . . . . . . . . 69
[RS_Diag_04263] Support of Target Modes . . . . . . . . . . . . . . . . 70
[RS_Diag_04264] SOVD specific Locking/Semaphore mechanism . . . 70
[RS_Diag_04265] Software Update . . . . . . . . . . . . . . . . . . . . . 70
[RS_Diag_04266] Bulk data . . . . . . . . . . . . . . . . . . . . . . . . . 70
[RS_Diag_04267] Logging . . . . . . . . . . . . . . . . . . . . . . . . . . 71
[RS_Diag_04268] Authentication . . . . . . . . . . . . . . . . . . . . . . 71
[RS_Diag_04269] SOVD 2 UDS Adapter . . . . . . . . . . . . . . . . . . 71
4.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5 Requirements Tracing 72

6 References 75
6.1 Deliverables of AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Related standards and norms . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.1 ITEA-EAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

1 Scope of the Document

This document specifies system requirements of AUTOSAR Diagnostic. It is meant
to be independent of any particular implementation and it contains foundation require-
ments, common to AUTOSAR Classic and Adaptive Platform, as well as requirements
specific to Classic Platform and Adaptive Platform.
In the Classic Platform chapter the handling of the legislated OBD and enhanced Di-
agnostics shall be achieved. As far as possible the set of diagnostic basic software
elements should consist of already existing elements of modules of automotive soft-
ware. Only in case of good reasons valid elements of basic software should be part of
the set. If such the definition of these valid elements is not part of this work package.
Nevertheless the information about basic software elements additionally required shall
be given to related work groups.
In the Adaptive Platform chapter, some constraints should be notify related to the
Adaptive environment: - only support for Ethernet as physical communication in-
frastructure will be provided, and no other typical bus communication is planned for
release 1.0; on these grounds, all classical SRS Diagnostics requirements referring to
standards (i.e. J1939) considering other bus protocols (i.e. FlexRay, CAN .. ) were not
considered in this specification
- due to insufficient information about the car domains where the AUTOSAR Adaptive
Platform will apply, OBD protocol (standardized as ISO 15031) is also not subject of
this specification
- Release 1.0 of AUTOSAR Adaptive Platform is planned to be a learning environment
for future development as a consequence its interfaces are described with ICC1 (In-
terface Conformance Class) granularity level, meaning that no internal DM interfaces
are to be specified

12 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

2 Acronyms and Abbreviations

Abbreviation / Acronym: Description:

CAN Controller Area Network (communication bus)

Dem Diagnostic Event Manager

DID Diagnostic Identifier

DM Diagnostic Management

DoIP Diagnostic over IP - transport protocol for diagnostic services

standardized as ISO 13400

DTC Diagnostic Trouble Code

ECU Electronic Control Unit

IDL Interface Description Language

OBD On-board Diagnostic (standardized as ISO 15031)

RTE Runtime Environment

SA Source Address (diagnostics address of the tester)

SID Service Identifier (hexa number to uniquely identify UDS ser-

vices)
0x22 for Read Data by Identifier service
0x2E for Write to Non-Volatile memory service

SWC Software Component (could refer either to Classic Platform SW-

C or to Adaptive Platform SW-C)

TA Target Address (diagnostic address of the ECU)

UDS Unified Diagnostic Specification standardized as ISO 14229

Table 2.1: table:acronyms

13 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

3 Conventions to be used
In requirements, the following specific semantics are used :
The key words ”MUST”, ”MUST NOT”, ”REQUIRED”, ”SHALL”, ”SHALL NOT”,
”SHOULD”, ”SHOULD NOT”, ”RECOMMENDED”, ”MAY” and ”OPTIONAL” in this doc-
ument are to be interpreted . Note that the requirement level of the document in which
they are used modifies the force of these words.
• SHALL: This word means that the definition is an absolute requirement of the
specification.
• SHALL NOT: This phrase means that the definition is an absolute prohibition of
the specification.
• MUST: This word, or the terms ”REQUIRED” or ”SHALL”, mean that the definition
is an absolute requirement of the specification.
• MUST NOT: This phrase, or the phrase ”SHALL NOT”, means that the definition
is an absolute prohibition of the specification.
• SHOULD: This word, or the adjective ”RECOMMENDED”, mean that there may
exist valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.
• SHOULD NOT: This phrase, or the phrase ”NOT RECOMMENDED” mean that
there may exist valid reasons in particular circumstances when the particular be-
havior is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with
this label.
• MAY: This word, or the adjective ”OPTIONAL”, means that an item is truly op-
tional. One vendor may choose to include the item because a particular market-
place requires it or because the vendor feels that it enhances the product while
another vendor may omit the same item. An implementation, which does not in-
clude a particular option, MUST be prepared to inter operate with another imple-
mentation, which does include the option, though perhaps with reduced function-
ality. In the same vein an implementation, which does include a particular option,
MUST be prepared to inter operate with another implementation, which does not
include the option (except, of course, for the feature the option provides).

14 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4 Requirements Specification

4.1 Common Diagnostic requirements for Classic and Adaptive

Platform
[RS_Diag_04200] Support event combination d

The diagnostic in AUTOSAR shall allow combining several individual events to

Description:
trigger a single DTC.
Rationale: Advanced fault analysis
AppliesTo: CP, AP
Dependencies: –
Improved clustering and judging of events/faults. Several internal hardware
faults of an electronic control unit can be mapped onto a single "ECU internal"
Use Case:
failure to reduce the number of Diagnostic Trouble Codes shown to the
technician in the service workshop.

c(RS_Main_00260)
[RS_Diag_04150] Support the primary fault memory defined by ISO 14229-1 d

The diagnostic in AUTOSAR shall support the primary fault memory defined by
Description:
ISO 14229-1.
Rationale: Storage of fault information for workshops.
AppliesTo: CP, AP
Dependencies: Production line, garage after reparation,...
The primary fault memory is used to store fault information that is related to
Use Case:
defects in the vehicle and helps the workshops to identify the fault and repair it.
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04214] Support the user defined fault memories defined by ISO 14229-
1d

The diagnostic in AUTOSAR shall support the user defined fault memories
Description:
defined by ISO 14229-1.
Rationale: Independent storage of fault information.
User defined fault memories are used by OEM and Tier1 during development
or for storing warranty relevant information inside. This information is also
Use Case: available for workshops or repairing the vehicle if the information stored in the
user defined memory it is helpful for this task (e.g. to distinguish defective
maintenance such as miss calibration from obvious malfunctions).
AppliesTo: CP, AP
Dependencies: –
5

15 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting ISO 14229-1 v.2013
Material:

c(RS_Main_00260)
[RS_Diag_04068] The diagnostic in AUTOSAR shall support event specific de-
bounce counters to improve signal quality internally (According to ISO 14229-1
Appendix D) d

The following types of debounce mechanisms shall be supported: The

diagnostic in AUTOSAR module shall provide the ability to configure the jump
behavior including jump up and jump down threshold value of the debounce
counter in case of pre-passed or pre-failed event reporting. If failure detection
Description: jitters (e.g. sporadically reported pre-passed events), failure detection must not
be delayed or prevented. The provision of jumping behavior of the debounce
counter shall ensure the failure detection time because debouncing always
starts from a defined starting point.This type of counters can be managed
either internally or externally.
Rationale: Advanced fault analysis
All applications and system modules can report events. The diagnostic module
Use Case: processes all these events and is able to provide a central de-bounce behavior
for event classification and status management.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04225] The diagnostic in AUTOSAR shall support event specific time
base debounce counters d

The diagnostic in AUTOSAR shall support event specific time base debounce
counters. The time based debouncing use a configurable time instead of
counter threshold. The time is reloaded and running after the last monitor
Description:
result/event status is different to the previous. After the time is exceeded the
event has qualified.This type of counters can be managed either internally or
externally.
Rationale: Advanced fault analysis
All applications and system modules can report events. The diagnostic module
Use Case: processes all these events and is able to provide a central de-bounce behavior
for event classification and status management.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260, RS_Main_00420)

16 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04115] The optional parameter DTCSettingControlOptionRecord as

part of UDS service ControlDTCSetting shall be limited to GroupOfDTC d

ISO14229-1 does not specify how the parameter

Description: DTCSettingControlOptionRecord needs to be used. Therefore, the usage of
the parameter shall be limited to GroupOfDTC.
Currently, no other use case for parameter DTCSettingControlOptionRecord is
Rationale: known than the usage for GroupOfDTC.
Use Case: Fault storage is activated and deactivated for one specific DTC or for all DTCs.
AppliesTo: CP, AP
Dependencies: –
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00260)
[RS_Diag_04064] Provide configurable buffer sizes for storage of the events,
status information and environmental data d

Diagnostic in AUTOSAR shall provide configurable buffer sizes to store events,

status information and environmental data. Due to resource limitation, only a
Description: few of the possible event related data is stored in the ECU. The system
designer shall be able to dedicate an amount of non-volatile memory to be
used for fault memory storage.
Storage of all event related data is not feasible due to the amount of required
Rationale: memory. This configurable buffer sizes allow to dedicate memory independent
from the number of events or event related data size.
In case of large systems with many events a selection of events shall take place
Use Case:
to fulfill NVRAM / RAM constraints of smaller processors.
AppliesTo: CP, AP
Dependencies: –
Supporting
Material:

c(RS_Main_00011)
[RS_Diag_04172] Inform external service processors about outcome of the final
response d

For each UDS service which diagnostic in AUTOSAR delegates to a application

Description: for processing, it shall inform the application, whether a response has been
successfully sent out or not.
For long running service processing, which delegate the processing to separate
Rationale: threads, the asynchronous callback model is more efficient, while for simple
service processors the strict synchronous model is easier to implement.
AppliesTo: CP, AP
Dependencies: [RS_Diag_04169]
5

17 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Use Case: Flexibility for service processor implementations.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04127] Configurable record numbers and trigger options for DTCSnap-
shotRecords and DTCExtendedDataRecords d

The diagnostic in AUTOSAR module shall provide the capability to configure

Description: record numbers and trigger options for the storage of DTCSnapshotRecords
and DTCExtendedDataRecords.
Rationale: Advanced fault analysis
Use Case: Flexible handling of DTCSnapshotRecords and DTCExtendedDataRecords
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04177] Custom diagnostic services d

The diagnostic in AUTOSAR shall support the configuration of custom

Description:
diagnostic services.
In some cases diagnostic services beyond the set of services standardized in
Rationale: ISO 14229-1 are needed.

AppliesTo: CP, AP
Dependencies: [RS_DEXT_00047]
Most of the services that are in ISO 14229-1 and are also specified by
AUTOSAR. Modifying the existing services behavior or adding customized
Use Case: behavior to existing services (e.g. not having session P2 timing values in the
positive response to diagnostic session control or adding specific services such
as "data log" services).

c(RS_Main_00260)
[RS_Diag_04059] Configuration of timing parameters d

Every physical layer requires specific timing parameter values therefore it is

necessary to include the ability to configure the timing constraints depending
Description:
on the used network. The timing parameters are set to default values when a
communication starts and shall be changeable at runtime.
Rationale: Usability with different networks.
The diagnostic communication can be done at different networks (e.g.
Use Case:
CAN/LIN/FlexRay/Ethernet).
AppliesTo: CP, AP
Dependencies: –
5

18 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting
Material:

c(RS_Main_00011, RS_Main_00260)
[RS_Diag_04033] Support the upload/download services for reading/writing data
in an ECU in an extended and manufacturer specific diagnostic session d

The diagnostic in AUTOSAR shall support the UDS services

RequestDownload, RequestUpload, TransferData, RequestTransferExit
Description: (0x34-0x37) according to ISO 14229-1:2013. Note that in the Classic Platform
these services are usually also implemented inside the bootloader which is out
of scope of this requirement.
Rationale: Provide means to upload and download data blocks.
Downloading configuration or application data during end of line or
Use Case: development. Another use case is uploading data blocks from the ECU for
evaluation or verification purposes.
AppliesTo: CP, AP
Dependencies:
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011)
[RS_Diag_04020] Suppress responses to diagnostic tool requests d

The diagnostic in AUTOSAR shall support the

Description: suppressPosRspMsgIndicationBit and the defined behavior according to ISO
14229-1:2013.
The tester is not interested in the positive response in certain situations. It
Rationale: prevents bus burst as result of a functional request.
In most cases, the positive responses are not relevant for functional requests to
set the vehicle in a certain state. This can be a sequence of service 0x85, 0x28
Use Case: and functional 0x3E during reprogramming to keep the vehicle in a ’silent’ state
without normal bus communication and DTC setting switched off.
AppliesTo: CP, AP
Dependencies:
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011)
[RS_Diag_04119] Handle the execution of diagnostic services according to the
assigned diagnostic session d

If a diagnostic session transition occurs (initiated by UDS Service 0x10), the

Description: diagnostic in AUTOSAR shall only maintain active diagnostic functionality if
supported in the new session and if not prohibited by security access.
5

19 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Rationale: No interruption of diagnostic functionality
Deactivation of fault management and normal communication during ECU
Use Case: reprogramming
AppliesTo: CP, AP
Dependencies:
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011)
[RS_Diag_04016] Support ”Busy handling” by sending a negative response 0x78
d

The diagnostic in AUTOSAR shall provide the sending of the negative response
Description:
0x78 in order get more time to build up the final positive or negative response.
Ensure a steady and save communication link and guarantee specified timing
Rationale:
conditions.
Use Case: When an application cannot provide the response in the protocol specific time
AppliesTo: CP, AP
Dependencies:
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011)
[RS_Diag_04006] Manage session handling d

The diagnostic in AUTOSAR shall support the transition from a default session
Description: to any other session, also back to the default session. (A diagnostic session
enables a specific set of diagnostic services and/or functionality).
Some diagnostic services are not available in the default session. Therefore it
is necessary to have information about the current session and no service
Rationale:
which is connected to a non default session will be processed in the default
session.
Special services need a different session than the default session, e.g.
Use Case: Reduction of communication traffic on the network in order to get more
performance for the flash programming.
AppliesTo: CP, AP
Dependencies: [RS_Diag_04005] SecurityAccess level handling
Supporting –
Material:

c(RS_Main_00011)

20 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04005] Manage Security Access level handling d

The diagnostic in AUTOSAR shall manage the handling of the UDS-service

Description: 0x27 (SecurityAccess) and also the Security level handling. The accessibility of
the services (service identifier) in the actual security level shall be checked.
Some diagnostic services are in dependence to a security access level.
Rationale: Therefore it is necessary to have information about the current level and no
service which is restricted by security will be processed without authorization.
Use Case: Not all diagnostic services are allowed in each security level.
AppliesTo: CP, AP
Dependencies:
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04135] Support UDS service $38 (RequestFileTransfer) d

The diagnostic in AUTOSAR shall support UDS service 0x38

Description:
("RequestFileTransfer”).
The requestFileTransfer service is used by the client to initiate a file data
transfer from either the client to the server or from the server to the client
Rationale:
(download or upload). Additionally, this service has capabilities to retrieve
information about the file system
Use Case: Upload of files (e.g. data files, graphics, navigation data...)
AppliesTo: CP, AP
Dependencies: [RS_Diag_04059] Configuration of timing parameter
Supporting ISO 14229-1 v.2013
Material:

c(RS_Main_00011)
[RS_Diag_04098] Interact with standard bootloader d

Integration of a standard bootloader into the AUTOSAR architecture.

• If the diagnostic in AUTOSAR is requested to change into the
programming session ($1002), it shall either send the final response and
then activate the bootloader or it shall not send the final response and
activate the bootloader where the activate the bootloader and the final
response shall be sent by the bootloader (according HIS [FL-504]).
Description:
• The diagnostic in AUTOSAR shall be able to check environmental
conditions (e.g. engine speed) before activating the bootloader.

• The diagnostic in AUTOSAR shall provide a configurable NRC 0x78

(RCRRP, retrigger the timeout supervision of the diagnostic client)
response during transition to the bootloader.
5

21 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Rationale: Bootloader concept has to be standardized within AUTOSAR.
Use Case: Usage of ”off-the-shelf” bootloader
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04159] Control of DTC storage d

The diagnostic in AUTOSAR shall support control of DTC storage via UDS
Description:
service 0x85.
Rationale: Avoiding unwanted storage of DTCs.
No DTCs storage when functional communication is deactivated during ECU
Use Case: reprogramming.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04157] Reporting of DTCs and related data d

Description: The diagnostic in AUTOSAR shall provide the reporting of DTCs and related
data.
Rationale: Report failure memory data to the requester.
Use Case: All services reporting fault memory data.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04156] Support DTCFunctionalUnit d

The diagnostic in AUTOSAR shall support DTCFunctionalUnit according to ISO

Description:
14229-1.
Rationale: Compliance to ISO 14229-1.
Use Case: OEM-specific use of DTCs.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)

22 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04077] Uses standard mechanisms provided by persistency modules

d

Description: –
Rationale: Non volatile data storage
Triggered data storage during normal ECU operation to avoid loss of volatile
Use Case:
data / event information.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00130, RS_Main_00440)
[RS_Diag_04131] Consistent event management mechanisms d

Description: All memory locations shall use the same event management mechanisms.
Rationale: Ensure identical event management behavior.
Use Case: –
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04117] Configurable behavior for DTC deletion d

Usually, only ClearAllDTCs is used for the deletion of DTCs. Therefore, a

Description: configurable behavior which optionally limits the deletion of DTCs to
ClearAllDTCs.
Rationale: OEM specific behavior
Use Case: Allow only ClearAllDTCs and therefore optimization of ClearDTC behavior.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04107] Provide defensive behavior d

For safety-related applications, the diagnostic in AUTOSAR shall ensure data

Description:
integrity of fault information stored in non-volatile memory.
Rationale: Error protection of fault memory is needed for safety-related applications
Use Case: Fault memory could have been corrupted
AppliesTo: CP, AP
5

23 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Dependencies: –
Use the optional CRC and redundancy capabilities provided by the AUTOSAR
persistency modules for stored fault memory blocks. Only blocks assigned to
Supporting
error events of high severity can be protected. These blocks can be stored in
Material:
non-volatile memory when the error event is confirmed (before shutdown of the
ECU)

c(RS_Main_00011)
[RS_Diag_04105] Event memory management d

The diagnostic in AUTOSAR shall be able to handle valid events, update

existing event memory entries or replace events in case of a full event memory.
Description: The processing is triggered externally (e.g. by the reported event status) or
depends on internal information (e.g. value of debounce counter
\timer,occurrence counter, ...)
Rationale: Support of fault storage and analysis
Use Case: Support of fault storage and analysis
AppliesTo: CP, AP
Dependencies: –
Supporting ISO 14229-1 v.2013
Material:

c(RS_Main_00420)
[RS_Diag_04091] Notification about valid freeze frame data to applications d

The diagnostic in AUTOSAR shall be enabled to notify other applications (or

system modules) about valid freeze frame data (e.g. time stamp). If this
Description:
functionality is configured for an event, it shall be executed every time a valid
freeze frame is stored in the event memory.
Providing freeze frame data (like time stamp) to applications or system
modules.
Rationale: Additionally this functionality provides a simple way for providing this data to
other components (every time valid data is available) to avoild cyclic polling.
The information provided by this functionality is needed by modules like a
Use Case: special ’Diagnostic active response handler’.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)

24 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04151] Event status handling d

Description: Diagnostics shall support event status handling.

Rationale: Support OEM specific event status handling
Use Case: Evaluation of monitor results and deriving corresponding actions from them
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04071] Process events according to their defined importance like pri-
ority and/or severity d

The events shall be sorted or assigned to a specific priority (e.g. Severity Mask
- ISO14229-1 v.2013,Annex D3) representing their importance like:
Description: • Healed events can be overwritten;
• Privileged storing in case of Event Buffer filled up with less privileged
events.
Rationale: ISO14229-1 v.2013
Use Case: Improved clustering and judging of events.
AppliesTo: CP, AP
Dependencies: –
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00260)
[RS_Diag_04125] Event debounce counter shall be configurable d

It shall be configurable if the debounce counter shall be frozen or reset, when at

least one enable condition for the event is set to ”not fulfilled” or when
ControlDTCSetting is set to ”disabled”.
Description: In case of switching the enable conditions to ”fulfilled” the monitor needs to be
informed to restart the event detection.
In case of switching ControlDTCSetting to ”re-enabled” the monitor needs to be
informed to restart the event detection.
Rationale: Flexible usage of internal debouncing
Use Case: –
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00420)

25 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04136] Configurable ”confirmed” threshold d

Description: The diagnostic in AUTOSAR shall support a postbuild configurable ”confirmed”

threshold.
Rationale: Flexible usage of local legislated requirements.
Support different legislated requirements in different markets (US/EURO).
For the US market the MIL and the ConfirmedDTC is activated after 2 DCY
Use Case: (Driving Cycles).
For the EUR market the MIL and the ConfirmedDTC is activated after 3 DCY
(Driving Cycles).
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04140] Aging for UDS status bits ”confirmedDTC” and ”test-
FailedSinceLastClear” d

The diagnostic in AUTOSAR shall provide the capability to age both the
confirmedDTC bit and the testFailedSinceLastClear bit after a configurable
Description:
number of aging cycles has been reached. The value at which each bit is aged
may be different between the two.
Rationale: –
Use Case: –
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04232] Access rights in client certificates d

The client certificate extensions shall contain well-defined data with diagnostic
access rights. The following access rights types shall be available:
• Role based access rights
• Dynamic access rights

Description: For role based access rights, the ECU maintains information about diagnostic
services allowed to be executed if the tester has gained authentication in that
role. The valid client certificate sets the tester into that role. Certificates can
contain multiple roles to be active at the same point in time.
For dynamic access rights, the certificate contains a whitelist of allowed
diagnostic services to be executed. The white list access shall allow wildcards
5
5

26 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
4
on PDU level. Both access right types can be active at any point in time and a
logical ’Or’ operation shall be applied.
The structured data layout of the certificate’s access rights content shall be
specified by AUTOSAR.
Only well-defined client certificate shall be accepted by diagnostics in
Rationale: AUTOSAR that allows a standardized handling and evaluation of certificates
and content.
The OEM PKI issues a certificate for a repair shop with role based or individual
Use Case: access rights for diagnostic services.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04233] Access granularity of diagnostic services d

Certificates provide role based and individual access rights definition.

Diagnostics in AUTOSAR shall provide a diagnostic service access right by
evaluation properties of services to be executed in the following order:
• service ID (SID)
• service Id and sub-function (SF)
Description:
• data identifier (DID)
• routine identifier (RID).

A service can be executed, if any of the above properties is part of the role or
current dynamic access rights (white list).
A definition is required how, the diagnostic service is identified to be executed.
Especially the level of granularity is important to reduce the resource
Rationale: consumption to a minimum. The SID check is very coarse but efficient, for
services with sub-function the sub-function can be taken into account. Further
services with DIDs and RIDs are identified by this identifier only.
An authentication state allows to execute any ECU reset service, is restricted to
Use Case:
extended session, allows 5 DIDs and one RID to be executed.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)

27 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04234] Binary compatibility of white list for individual access d

Diagnostics in AUTOSAR shall specify the white list binary layout. This layout
Description:
shall be compatible for all ECUs independent from the endianness in place.
A definition is required how a white list shall look like so it can be downloaded
Rationale:
into any ECU software independent from the used implementation.
A certain binary layout for a white list shall define a well-defined set of
Use Case: diagnostic services that are allowed to be executed.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04235] Client certificate validity d

Diagnostics in AUTOSAR shall evaluate the client certificates validity period

Description:
and refuse expired our not yet valid certificates.
Rationale: Control the certificate lifetime and limit the potential of outdated certificates.
Use Case: The OEM PKI issues a certificate (e.g. for a repair shop) for a defined period.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04236] Client certificate target identification d

Diagnostics in AUTOSAR shall provide standardized means for target

Description: identification. A target can be identified by OEM defined criteria such as VIN,
vehicle line or ECU type.
Rationale: Control the certificates validity on defined targets only.
The OEM PKI issues a certificate for a vehicle with a certain VIN or an only for
Use Case:
one type of ECU.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)

28 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04237] Client certificate evaluation d

Diagnostics in AUTOSAR shall use the diagnostic policy manager to evaluate

client certificates from service 0x29 requests. The result of a certificate
Description: evaluation is the decision if the certificate is valid and which diagnostic services
are allowed for execution. Based on the active certificate it grants access for
received diagnostic requests.
AUTOSAR shall define the semantics for the certificate payload. This allows to
Rationale: have a standardized check for certificate validities and evaluation of contained
access rights.
A repair shop diagnostic tester initiates an authentication by sending its
Use Case: certificate. A set of diagnostic services is available to the diagnostic tester after
authentication.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04238] Logging certificate evaluation d

The diagnostic policy manager shall report a security event every time a
Description: certificate is passed for evaluation. The event data shall contain at least the
result of the certificate evaluation.
Forensic analysis and interested parties require information which kind of
Rationale: access was requested and granted to diagnostic testers.
A certificated with extended access rights is provided by the diagnostic tester.
Use Case: A security event provides information about that specific certificate was
provided to the ECU.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04239] Diagnostic services in deauthenticated state d

Diagnostics in AUTOSAR shall have a configuration to allow execution of

Description:
dedicated diagnostic services in deauthenticated state.
At least the services to authenticate the tester, shall be available in all
Rationale:
authentication states.
Sending a service 0x29 in deauthenticated state to reach an authentication
Use Case:
state.
AppliesTo: CP, AP
Dependencies: –
5

29 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04240] Application based authentication d

Description: Diagnostics in AUTOSAR shall provide means to applications to change the

authentication state of unauthenticated connections.
An individual authentication with each ECU in the vehicle might be take too
Rationale:
much time some for some applications.
An application based centralized authentication broadcast is required to gain
Use Case: access to a set of diagnostic services.
AppliesTo: CP, AP
Dependencies: –
Supporting Concept 636 "Security Extensions"
Material:

c(RS_Main_00170)
[RS_Diag_04133] Aging for event memory entries d

The diagnostic in AUTOSAR shall support aging for event memory entries to
Description: remove entries from the event memory which have not failed for a specific
number of operating cycles.
Rationale: Remove information from fault memory that is not relevant for a repair action.
Network timeout fault that has been detected, but is not in active state any
Use Case:
more.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04063] Process a dedicated event identifier for each monitoring path
to support an autonomous handling of different events/faults d

For the internal administration the diagnostic in AUTOSAR needs a unique

Description: identification of each monitoring path. This identification shall be handled via an
event ID value (Integer).
Rationale: A monitoring path shall be uniquely identified by its unique event ID value.
Use Case: Unique fault identification which can be used for enhanced debugging.
AppliesTo: CP, AP
Dependencies: –
5

30 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04148] Provide capabilities to inform applications about diagnostic
data changes d

The diagnostic in AUTOSAR modules shall provide capabilities to inform

applications about diagnostic data changes. The capabilities shall cover the
Description:
provision of corresponding interfaces and configuration options for data
elements and associated triggers.
Rationale: Applications requires information about data changes.
Applications needs to be informed about a status change of a DTC to be able
Use Case:
to react on this DTC status.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04097] Decentralized and modular diagnostic configuration in appli-
cations d

Applications can provide diagnostic information. The diagnostic in AUTOSAR

Description: module shall be able to generate ports to be connected to these applications in
order access this diagnostic data.
Because of decentralized configuration and interface requirements each
Rationale: application shall provide and implement diagnostic interfaces to allow code
generation and port connection
Use-case example:
• As of today functions and associated diagnostics are developed by
several parties. Thus for each function and its monitoring application
(e.g. torque management in an engine controller)the diagnostic
capabilities are defined separately and will not necessarily be
coordinated during development.
Use Case:
• System integration and combination of diagnostics for accessibility
through diagnostic in AUTOSAR requires that the individual functions
and diagnostic features are connected to be compiled as a complete
diagnostic system (which is in case of OBD2 certification relevant).

Use-case summary:
5
5

31 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
4
1. develop decentralized modular software and its diagnostics without
permanent interaction with other application developers.
2. Combine modules and extract module-specific diagnostic data.
3. link diagnostic data from applications to the diagnostic in AUTOSAR.
AppliesTo: CP, AP
Dependencies: –
Supporting ISO 14229-1 v.2013
Material:

c(RS_Main_00420, RS_Main_00260)
[RS_Diag_04067] Provide the diagnostic status information according to ISO
14229-1 d

The diagnostic in AUTOSAR shall provide the diagnostic status information

Description: according to the DTCStatusMask, ISO 14229-1 v.2013 (refer to DTC status
mask), Annex D5
Rationale: Advanced fault analysis
Use Case: Improved fault and event tracking and analysis
AppliesTo: CP, AP
Dependencies: –
Supporting ISO 14229-1 v.2013
Material:

c(RS_Main_00420, RS_Main_00260)
[RS_Diag_04179] Provide interfaces for monitoring application. d

AUTOSAR Diagnostics shall provide an interface to monitoring application for

Description: reporting and processing monitor results. The reported result shall uniquely be
identified by an EventID.
Test results reported by monitoring applications are handled diagnostic in
Rationale: AUTOSAR internally. The interaction between diagnostic in AUTOSAR and the
application is realized using a dedicated interface.
AppliesTo: CP, AP
Dependencies: –
Monitoring applications report test results as soon as valid results are available
Use Case: by using the provided interface.

c(RS_Main_00260)

32 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04178] Support operation cycles according to ISO 14229-1 d

The diagnostic in AUTOSAR shall provide a configurable set of system cycles

Description:
that may qualify the event in an additional manner.
Rationale: Operation cycles are essential for event status management.
AppliesTo: CP, AP
Dependencies: –
Use Case: Starting of an operation cycle triggers many types of system reactions.
Supporting ISO 14229-1 v.2013 and ISO 15031-5
Material:

c(RS_Main_00260)
[RS_Diag_04201] Support a configuration to assign specific events to a customer
specific DTC d

Description: Assignment of events to customer specific or standardized DTCs.

Events are used diagnostic in AUTOSAR internally only. An external scan tool
Rationale: requests a DTC number which was assigned to one or multiple events/monitors.
AppliesTo: CP, AP
Dependencies: –
Internal monitor results (e.g. driver can be experienced) are observable via a
Use Case: scan tool enabling external fault analysis.

c(RS_Main_00260)
[RS_Diag_04180] Process all UDS Services related to diagnostic fault memory of
ISO 14229-1 internally d

Service implementation of all UDS services, which are related to fault memory
Description: shall be implemented internally within diagnostic in AUTOSAR without
delegating the processing/part of the processing to external modules.
Since diagnostic in AUTOSAR is also responsible for fault memory
Rationale: management, all fault memory related UDS services have to be processed
internally.
AppliesTo: CP, AP
Dependencies: –
Use Case: Fault memory handling like 0x85, 0x14, 0x19 have to be processed internally.
Supporting ISO 14229-1
Material:

c(RS_Main_00260)

33 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04182] Provide an application interface to change operation cycles

states d

Operation cycles handled by the diagnostic in AUTOSAR can be restarted by

Description:
application.
Operation cycle state transitions are trigger conditions for event status
Rationale: management according to ISO 14229-1.
AppliesTo: CP, AP
Dependencies: [RS_Diag_04178]
Monitoring application restarts an operation cycle. This triggers some status
Use Case: changes for the relevant events.

c(RS_Main_00060)
[RS_Diag_04183] Notify interested parties about event status changes d

Description: Event status change report shall be available for application subscribing for the
notification.
Event specific status information is handled diagnostic in AUTOSAR internally,
Rationale: the change of the status might be relevant for monitoring or other applications.
AppliesTo: CP, AP
Dependencies: –
Use Case: The application gets informed about relevant event status change.

c(RS_Main_00060)
[RS_Diag_04185] Notify applications about the clearing of an event d

Description: Interested monitoring application shall be notified about the clearing of event
status information and event related data.
Rationale: Monitor reinitialization can be triggered by the clear notification.
AppliesTo: CP, AP
Dependencies: –
After the event status is cleared diagnostic in AUTOSAR informs the relevant
Use Case: monitoring application which can be reinitialized.

c(RS_Main_00060)
[RS_Diag_04186] Notify applications about the start or restart of an operation
cycle d

Interested monitoring application shall be informed about the start or restart of

Description:
operation cycles.
Rationale: Monitor reinitialization can be triggered by the start of an operation cycle.
AppliesTo: CP, AP
Dependencies: –
5

34 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
A monitor application gets initialized after diagnostic in AUTOSAR informs it
Use Case:
about the start of a relevant operation cycle.

c(RS_Main_00060)
[RS_Diag_04204] Provide the current status of each warning indicator. d

The diagnostic in AUTOSAR shall derive the current warning indicator status
Description: from the assigned events according to ISO 14229-1. The
warningIndicatorRequested bit shall be set according to ISO 14229-1.
The warning indicator status is used to activate or deactivate indicators like
Rationale: lamps, text message or a beep. The state is calculated in diagnostic in
AUTOSAR wherefore the information needs to be distribution to the application.
AppliesTo: CP, AP
Dependencies: –
Indications of certain malfunctions to the driver (e.g. Malfunction Indicator
Use Case:
Lamp (MIL)).

c(RS_Main_00060, RS_Main_00420)
[RS_Diag_04205] Support of SnapshotRecords d

The diagnostic in AUTOSAR shall support SnapshotRecords according to ISO

14229-1.
Each DTC can optionally have one or more SnapshotDataRecords. The
supported record numbers shall be configurable. Only a atomic update of the
Description: whole record shall be supported. The storage trigger shall be configurable per
snapshot record number. The configurable trigger is based on the following
DTC status bit transitions: TestFailed_Set; Confirmed_Set; Pending_Set
FaultDetectionCounterThreshold_Reached.
The environmental data shall be captured from external applications.

Rationale: Advanced fault analysis.

AppliesTo: CP, AP
Dependencies: [RS_Diag_04189]
Use Case: Improved clustering and judging of events/faults.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)

35 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04206] Support of ExtendedDataRecords d

The diagnostic in AUTOSAR shall support ExtendedDataRecords according to

ISO 14229-1.
Each DTC can optionally have one or more ExtendedDataRecords. The record
numbers shall be configurable. Only a atomic update of the whole record shall
Description: be supported. The storage trigger shall be configurable per Extended data
number. The configurable trigger is based on the following DTC status bit
transitions: TestFailed_Set; Confirmed_Set; Pending_Set
FaultDetectionCounterThreshold_Reached.

Rationale: Advanced fault analysis.

AppliesTo: CP, AP
Dependencies: [RS_Diag_04189]
Use Case: Improved clustering and judging of events/faults.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04189] Support a fine grained configuration for SnapshotRecords and
ExtendedDataRecords d

The diagnostic in AUTOSAR shall be able to handle fine grained layout

Description: configurations for event related data. Data elements might be collected from
different applications and merged to different DIDs or ExtendedDataRecords.
Rationale: Advanced fault analysis.
AppliesTo: CP, AP
Dependencies: –
diagnostic in AUTOSAR collects SnapshotRecord data from different
Use Case: application and merges diagnostic information into one DID.

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04190] Usage of internal data elements in SnapshotRecords and Ex-
tendedDataRecords d

It shall be possible to assign the diagnostic in AUTOSAR internal data elements

like Operation Cycle Counter, Fault Detection Counter (FDC) and Occurrence
Description: Counter to Snapshot- and ExtendedDataRecords. While reading the Snapshot-
or ExtendedDataRecord the current value of the diagnostic in AUTOSAR
internal data element shall be reported.
Some data objects that are internally generated by the diagnostic in AUTOSAR
Rationale:
can be retrieved by UDS service 0x19 ReadDTCInformation.
AppliesTo: CP, AP
Dependencies: [RS_Diag_04205]
Reading Operation Cycle Counter, Fault Detection Counter and Occurrence
Use Case:
Counter.

c(RS_Main_00260, RS_Main_00011)

36 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04192] Provide the ability to handle event specific enable conditions d

The diagnostic in AUTOSAR shall support enable conditions per event. If an

Description: event specific enable condition is not fulfilled, the reported event status is not
processed.
Support mechanisms to avoid large amounts of event memory entries in case
Rationale:
of specific ECU conditions.
AppliesTo: CP, AP
Dependencies: –
In certain vehicle conditions, such as engine cranking, it shall be avoided to
Use Case: evaluate the result of a monitoring application for a certain time.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04219] Provide the ability to handle event specific storage conditions
d

The diagnostic in AUTOSAR shall support storage conditions per event. If an

Description: event specific storage condition is not fulfilled, no event related data is captured
and UDS status bits 2 (PendingDTC) and 3 (ConfirmedDTC) is not processed.
Support mechanisms to avoid event memory entries in situations where the
Rationale:
event related data is of no interest.
AppliesTo: CP, AP
Dependencies: –
For certain events only safety related information (e.g. via Fim) are derived but
Use Case: the further processing can be skipped as another root cause is active and only
event related data for that root cause is stored.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04194] ClearDTC shall be accessible for applications d

The service ClearDTC provided by the diagnostic in AUTOSAR supports the

functionality of clearing the DTCs of a specified memory origin. This service
Description:
shall be available not only inside the diagnostic in AUTOSAR, but also for the
application.
The UDS job 0x14 ClearDiagnosticInformation supports only the clearing of
Rationale: primary memory. Clearing of user defined memory origins is usually handled by
the application, that is why the ClearDTC service shall be provided.
AppliesTo: CP, AP
Dependencies: –
A routine control UDS job activates application, which clears the DTCs of a
Use Case: user defined memory using the ClearDTC service in diagnostic in AUTOSAR.

c(RS_Main_00260, RS_Main_00060)

37 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04195] Chronological reporting order of the DTCs located in the con-

figured event memory d

The diagnostic in AUTOSAR shall be able to handle the order of event

Description:
occurrences (e.g. represented by a time stamp or odometer value).
Rationale: Advanced fault analysis.
AppliesTo: CP, AP
Dependencies: –
Use Case: When processing 0x19 UDS job, DTCs are returned in the chronological order.

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04211] Persistent storage of DTC status and environmental data d

The diagnostic in AUTOSAR shall support the non-volatile storage for event
Description:
status and environmental data parameters required by ISO 14229-1.
According to the ISO 14229-1 UDS specification a set of status information and
Rationale:
environmental data shall be stored non-volatile.
AppliesTo: CP, AP
Dependencies: –
Use Case: Status information is stored non-volatile over power cycles.
Supporting ISO 14229-1 Appendix D
Material:

c(RS_Main_00011)
[RS_Diag_04220] Support DTCs suppression d

The diagnostic in AUTOSAR shall provide the possibility to suppress DTCs to

Description: be visible in diagnostic services. Suppressed DTCs shall be available internally
and processed as any other DTCs
Rationale: DTCs need to be hidden in certain conditions (e.g. dedicated markets)
Use Case: Hide DTCs in certain markets
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04196] UDS Service handling for all diagnostic services defined in ISO
14229-2 d

The diagnostic in AUTOSAR shall implement the protocol handling for all UDS
Description:
services defined in ISO 14229-2.
The diagnostic in AUTOSAR shall be the central service handler for UDS
Rationale: diagnostics.
5

38 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
AppliesTo: CP, AP
Dependencies: –
Use Case: Interaction with UDS compliant tester on Ethernet.
Supporting ISO 14229
Material:

c(RS_Main_00260)
[RS_Diag_04203] Common checks on all supported UDS Services Requests d

For UDS services the support for the requested SID shall be checked by the
diagnostic module. If the service ID is valid and depending on the service ID,
Description:
the potential sub-function identifier shall be checked for support by the
diagnostic module.
The diagnostic in AUTOSAR shall be UDS compliant and shall do general
checks, which can be done on UDS protocol level centrally, independently
Rationale:
whether the service is processed internally or externally by a applications as
service processor.
AppliesTo: CP, AP
Dependencies: –
Use Case: It must verified if the services requested is supported or not (i.g. ClearDTC,...)
Supporting ISO 14229
Material:

c(RS_Main_00260)
[RS_Diag_04226] Diagnostic session check d

For UDS services the support for Diagnostic session shall be checked by the
Description:
diagnostic module.
The diagnostic in AUTOSAR shall be UDS compliant and shall do general
checks, which can be done on UDS protocol level centrally, independently
Rationale:
whether the service is processed internally or externally by applications as
service processor.
AppliesTo: CP, AP
Dependencies: –
Use Case: Session change should allow only specified changes.
Supporting ISO 14229
Material:

c(RS_Main_00260)

39 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04227] Common check for Security Access d

For UDS services the support for Diagnostic security level shall be checked by
Description:
the diagnostic module.
The diagnostic in AUTOSAR shall be UDS compliant and shall do general
checks, which can be done on UDS protocol level centrally, independently
Rationale:
whether the service is processed internally or externally by applications as
service processor.
AppliesTo: CP, AP
Dependencies: –
Use Case: To protect services from being accessed by non-authorized users.
Supporting ISO 14229
Material:

c(RS_Main_00260)
[RS_Diag_04228] Common check for Message lengths d

For UDS services the support for Message length shall be checked by the
Description:
diagnostic module.
The diagnostic in AUTOSAR shall be UDS compliant and shall do general
checks, which can be done on UDS protocol level centrally, independently
Rationale:
whether the service is processed internally or externally by applications as
service processor.
AppliesTo: CP, AP
Dependencies: –
The message length must be checked and if it does not respect a predefined
Use Case: range , the requested service will be rejected.
Supporting ISO 14229
Material:

c(RS_Main_00260)
[RS_Diag_04197] Clearing the user defined fault memory d

The clearance of user defined fault memory shall be possible according to the
ISO 14229 draft document:
Description:
“02_ISO_14229-1_Comments-Summary_2016-09-13.docx” via diagnostic
requests.
Rationale: Provide a standardized way to clear user defined fault memory.
AppliesTo: CP, AP
Dependencies: –
OEM and TIER1 using the user defined fault memory need to clear the user
Use Case: defined memory. A standardized way make OEM or TIER1 specific solutions
obsolete, which were incompatible to each.
Supporting ISO 14229-1
Material:

c(RS_Main_00260)

40 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04198] Process all UDS Services related to session and security man-
agement of ISO 14229 internally d

Service implementation of all UDS services, which are related to session and
security management (DiagnosticSessionControl, SecurityAccess and
TesterPresent from ’Diagnostic and Communication Management functional
unit’), shall be implemented internally within diagnostic in AUTOSAR without
Description:
delegating the processing/part of the processing to external modules. This
does NOT exclude, that diagnostic in AUTOSAR does callout to external
application for instance to get/check certain security keys. But the state
machine/protocol is handled internally by diagnostic in AUTOSAR.
Session and security management is an integral part of general UDS service
Rationale: handling and has therefore to be implemented internally.
AppliesTo: CP, AP
Dependencies: –
Use Case: General diagnostic protocol processing.
Supporting ISO 14229
Material:

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04199] Provide a configurable UDS service execution mechanism at
runtime to decide if a UDS request shall be processed or not d

The diagnostic in AUTOSAR shall support to query configured application,

Description:
whether a received UDS service request shall be processed or rejected.
Infrastructural/OEM specific supervisor components decide about service
Rationale:
execution on a basis of ECU/vehicle state.
AppliesTo: CP, AP
Dependencies: –
Use Case: Control of service access centrally done in one application.

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04208] Inform the application about diagnostic session and diagnostic
security level changes on each tester connection. d

In case the currently active UDS session or security level change on a tester
conversation, the diagnostic in AUTOSAR shall provide a notification
Description:
mechanism for the application, to inform the applications about the new
session or security level and the affected tester connection.
Session changes happen asynchronously to service processor
Rationale: implementations. But there exists functionality that needs to react on session
changes.
AppliesTo: CP, AP
Dependencies: [RS_Diag_04169]
Use Case: Flexibility for service processor implementations.

c(RS_Main_00260, RS_Main_00011)

41 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04218] Support of UDS service 0x2F InputOutputControlByIDentifier d

The Diagnostic Management shall support the ISO 14229-1 service 0x2F
Description:
InputOutputControlByIDentifier
Rationale: Allow to simulate input values and to control output values
AppliesTo: CP, AP
In workshop or production checks with the input and output channels of the
Use Case:
ECU is needed.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04222] Independence of clearing DTC status and system degradation
d

Description: Independence of clearing DTC status and system degradation

Clearing of DTCs must not influence the system degradation. Otherwise on a
Rationale: clear, the system would go to normal operation and cause serious issues with
functionalities (e.g. wrong actuation)
AppliesTo: CP, AP
To achieve clearing of DTC status information and simultaneously keep the
system degradation, it shall be possible for events to not to change their failed
Use Case: status upon a call of clear. Nevertheless status bytes of DTCs which are not
related to system degradation shall be cleared
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04224] Support the UDS service 0x31 (RoutineControl) according to
ISO 14229-1 d

The diagnostic in AUTOSAR shall support the ISO 14229-1 service 0x31
Description:
RoutineControl with all sub-functions
RoutineControl is an integral part of ISO 14229-1 and used in most ECUs for
Rationale: customer specific actions triggered by diagnostic services.
AppliesTo: CP, AP
Use Case: Diagnostic tester starts a routine in the server.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)

42 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04242] The DoIP module shall support Vehicle Internal Testers. d

In addition to external tester, The DoIP module shall support Vehicle Internal
Description:
Testers and shall reference the ISO standards 13400-2 for this purpose.
Rationale: Support in vehicle DoIP communication.
DoIP testers not just resides outside vehicle network but also possible to reside
Use Case: inside vehicle network. Support in vehicle DoIP communication.
AppliesTo: CP, AP
Dependencies: –
ISO 13400-2, Road vehicles – Diagnostic communication over Internet Protocol
Supporting
(DoIP) – Part 2: Transport protocol and network layer services ISO 13400-2
Material:
extension with Internal tester concept.

c(RS_Main_00260)
[RS_Diag_04147] Communication with the transport layers to receive and send
diagnostic data d

The diagnostic in AUTOSAR shall communicate with the transport layer

Description:
modules to receive and send diagnostic data.
Rationale: Ensure diagnostic communication.
Use Case: Support of various transport protocols (ISO-15765-2, ...).
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011, RS_Main_00260)
[RS_Diag_04244] Support sub-function 0x04 of UDS service 0x19. d

The diagnostic in AUTOSAR shall support sub-function 0x04 of UDS service

Description:
0x19 to retrieve snapshot records stored for DTCs.
Rationale: Provide means to retrieve snapshot records.
Use Case: capture data at various points in time when faults occur in the system.
AppliesTo: CP, AP
Dependencies: –
Supporting ISO 14229-1
Material:

c(RS_Main_00260)

43 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04245] Support sub-function 0x06 of UDS service 0x19. d

The diagnostic in AUTOSAR shall support sub-function 0x06 of UDS service

Description:
0x19 to retrieve extended data records stored for DTCs.
Rationale: Provide means to retrieve statistical data.
Use Case: Provide system internal statistical information assigned to a certain DTC.
AppliesTo: CP, AP
Dependencies: –
Supporting ISO 14229-1
Material:

c(RS_Main_00260)
[RS_Diag_04058] Ability to access different event memories d

The diagnostic in AUTOSAR shall support diagnostic services to read or

Description:
remove event entries from the configured event memory seperatly.
Rationale: Advanced fault analysis
The development departments of the OEMs and Suppliers need as much as
possible deeper fault/event analysis although the mechanics may have deleted
Use Case:
the faults or may not need to know if there are more detailed root causes for an
event or fault.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04160] ResponseOnEvent according to ISO 14229-1 d

Description: Diagnostics shall support ResponseOnEvent according to ISO 14229-1.

Rationale: Needed for failure analysis and fault memory tracking.
Use Case: Inform diagnostic tooling about certain runtime conditions.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04109] Provide an interface to retrieve the number of event memory
entries d

The diagnostic in AUTOSAR shall provide an interface to retrieve the number of

event memory entries currently stored in Primary and user defined memories to
Description:
the application. Additionally, the corresponding Client Server Interface shall be
provided.
5

44 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
The interface is required from application, to check if event memory entries
Rationale:
exist that influence the ECU behavior.
There is an application message where a status bit must be set as soon as
Use Case: events are stored in the event memory. Therefore, the application needs to
know how many event memory entries exist.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00420)
[RS_Diag_04246] Support of UDS service DynamicallyDefineDataIdentifier
(0x2C) with subfunction 0x01 (defineByIdentifier) d

The diagnostic in AUTOSAR shall support UDS service

Description: DynamicallyDefineDataIdentifier (0x2C) with subfunction 0x01
(defineByIdentifier) according to ISO 14229-1.
UDS defines this service to allow the client to dynamically define a data
Rationale:
identifier at a later point in time.
Read operations for tailored data identifier that are build out of a collection of
Use Case: parts or full content of existing data identifiers with UDS service 0x22/0x2A.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00420)
[RS_Diag_04215] Support of UDS service ReadDataByPeriodicIdentifier (0x2A) d

The diagnostic in AUTOSAR shall support UDS service

Description: ReadDataByPeriodicIdentifier (0x2A) with all supported sub-functions
according to ISO 14229-1.
Periodic transmission of measurements/data by the diagnostic server (ECU),
instead of frequent polling by re-requesting the same data via
Rationale: ReadDataByIdentifier. Further it is possible to reach higher update rates of
measurements (e.g. 2ms).
Use Case: Monitor measurement values over time by diagnostics.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)

45 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04248] Support of session control service d

The diagnostic in AUTOSAR shall support the UDS service 0x10

Description: (SessionControl) with all its mandatory sub-functions and allow to define the
vehicle manufacturer specific and system supplier specific sub-functions.
Sessions are a key aspect to control that an active tester connection is given
Rationale:
and restrict certain services to be executed only in certain sessions.
Execute certain diagnostic services only in timing secured sessions, fall back
Use Case: into default session will stop all started diagnostic activity in that session.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04249] Support of session layer service d

The diagnostic in AUTOSAR shall support the session layer services defined by
Description:
ISO-14229-2.
Rationale: OSI compliant network adaption.
Organizing the diagnostic communication within heterogeneous network
Use Case: systems (e.g.keep alive logic).
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04093] Memory overflow indication d

For each Event Memory it shall be indicated if the related event memory (e.g.
Description: primary and user defined memories) is full and the next event occurs to be
stored in this event memory.
The information that an event memory overflow occurred is very important for
Rationale:
fault analysis.
• Triggering further internal behavior (e.g displacement strategies)
Use Case: • Linking this information to a dedicated Extended Data Record
• Vendor specific UDS-Service
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)

46 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04118] Optionally support event displacement d

The diagnostic in AUTOSAR shall optionally support event displacement. The

following sequence of different displacement criteria shall be possible:
Description: 1. Priority;
2. Active/passive status (optional);
3. Occurrence.
Rationale: Limited hardware (memory resources) in ECU.
Use Case: Error memory is full and Valid event is reported to diagnostic in AUTOSAR.
AppliesTo: CP, AP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04120] Support a predefined AddressAndLengthFormatIdentifier d

The diagnostic in AUTOSAR shall support a predefined

AddressAndLengthFormatIdentifier for UDS service 0x23
(ReadMemoryByAddress), UDS service 0x2C
Description:
(DynamicallyDefineDataIdentifier (only CP) with subservice
DefineByMemoryAddress), UDS service 0x3D (WriteMemoryByAddress), UDS
service 0x34 (RequestDownload) and UDS service 0x35 (RequestUpload).
AddressAndLengthFormatIdentifier is defined once and afterwards used in
Rationale: corresponding UDS services.
Use Case: Static configuration of AddressAndLengthFormatIdentifier
AppliesTo: CP, AP
Dependencies: –
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011, RS_Main_00260)
[RS_Diag_04124] Store the current debounce counter value nonvolatile to over a
powerdown cycle d

The diagnostic in AUTOSAR shall be able to store the current debounce

Description:
counter value non-volatile to over a power-down cycle.
Rationale: Support of DTC de-bouncing within several power cycles.
While the typical DTC operation cycle for a DTC is to start at power up and end
at power down, there are different situations, when a particular DTC must
Use Case: define its operation cycle to span multiple ECU power up/down cycles. In this
case, the FDC would need to be stored in NVM as it may never make it to 127
during a single power up.
AppliesTo: CP, AP
Dependencies: –
5

47 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting –
Material:

c(RS_Main_00260, RS_Main_00420)

4.2 Diagnostic requirements for the Classic Platform

4.2.1 Functional Requirements

[RS_Diag_04112] The DEM module shall support DTCs according to SAE J1939
d

Description: The DEM module shall support DTCs according to SAE J1939-73.
Rationale: Support of SAE J1939-73
Use Case: Diagnostics in HDV, HD-OBD
AppliesTo: CP
Dependencies: DEM, J1939DCM
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04139] Support subfunction 0x42 of UDS service 0x19 d

The diagnostic in AUTOSAR shall support subfunction 0x42 of UDS service

Description: 0x19 to retrieve WWH-OBD-specific DTCs matching the requested DTC status
mask and severity mask record.
Rationale: Support of WWH-OBD
Use Case: Improved fault and event tracking and analysis
AppliesTo: CP
Dependencies: –
Supporting Support of WWH-OBD
Material:

c(RS_Main_00260)

48 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04129] Provide OBD-specific configuration capabilities d

The diagnostic in AUTOSAR shall provide the following configuration

capabilities:
• OBD- ECU kind 1: ECU acts as OBD Master ECU (Master or Primary
ECU)
• OBD- ECU kind 2: ECU acts as OBD Slave ECU (Dependent /
Secondary ECU)
Description: • OBD- ECU kind 3: ECU acts as non-OBD ECU

The diagnostic in AUTOSAR shall both provide corresponding configuration

parameters to switch on/switch off module-specific OBD functionality.
Depending on the configured use case, the associated application interfaces
shall be provided to connect different OBD-ECU kinds on application level (via
bus communication).
Rationale: UseCase-specific module configuration.
Use Case: Optimization of RAM/ROM consumption.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04163] Parallel OBD and UDS processing d

Description: Diagnostics shall support the parallel processing of OBD and UDS protocols.
Vehicles can be equipped with On-board testers which send diagnostic
Rationale: requests at any arbitrary point in time. Legislative OBD requests need to be
processed independently from a UDS requests from On-board testers.
Use Case: Parallel reception of diagnostic requests from multiple testers.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04161] Provide support for the ASMIP algorithm d

The diagnostic in AUTOSARs shall consider the ASMIP algorithm (Alternative

Description: Statistical MIL Illumination Protocol) according to the Californian Code of
Regulation 13 CCR section 1968.2.
Rationale: Supporting OBD use cases.
Use Case: Dynamical threshold modification.
AppliesTo: CP
5

49 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04230] Support of UDS service 0x29 (Authentication) d

Diagnostics in AUTOSAR shall support the ISO 14229-1:2020 service 0x29

Authentication with sub-functions for "Authentication with PKI Certificate
Description: Exchange (APCE)" to grant access to diagnostic services. The service shall be
implemented as internal service (in the BSW) without interaction with
applications over middleware.
The authentication service provides a standardized way in authenticating a
Rationale: tester and ECU and grant access to diagnostic services depending on the
certificate content.
A repair shop diagnostic tester authenticates with an ECU to gain access to
Use Case: diagnostic services that are explicitly allowed to be executed for a repair shop.
AppliesTo: CP
Dependencies: –
Supporting Concept 636 "Security Extensions" - C5, ISO14229-1:2020 Authentication
Material: Service 0x29

c(RS_Main_00170)

4.2.2 Fault Memory Management

[RS_Diag_04002] The Diagnostic event (fault) management shall be established

as Basic SW Module d

The Diagnostic event (error) management shall be a Basic SW Module

Description: described in the Diagnostic WP. Diagnostic event (error) management is out of
scope for Mode Management.
Rationale: SW Architecture
Improved fault and event tracking and analysis for Service, assembly line,
Use Case:
OBD-SCAN-Tool
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)

50 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04057] Classification of events for series production, OBD and expert

usage d

The diagnostic in AUTOSAR shall support a classification of events for the

following types of events:
• Events that are defined for error analysis in the service station shall be
stored in the primary event memory.
Description: • Events that are defined for detailed error analysis by experts in the after
sale department are stored in the secondary error memory.

Errors that occur during the development process shall be reported to the
debugging modules. Therefore, debugging module APIs shall be used which
(are not provided by the diagnostic in AUTOSAR).
Rationale: After sales analysis
Use Case: Distinction between service station relevant and after sales relevant events.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04123] Harmonized Driving//WarmUp cycles d

The diagnostic in AUTOSAR shall support harmonized Driving-/WarmUp

Description: cycles.
The calculation of Driving-/WarmUp cycles is based on legal requirements.
OBD certification requires vehicle consistent calculations based on a
Rationale: harmonized Driving-/WarmUp cycle in the centralized OBD Master ECU.
Use Case: Qualification of OBD-relevant DTCs
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04126] Configurable suppression of events d

The diagnostic in AUTOSAR shall provide a postbuild/loadable boolean

configuration option per event.
Description: If this configuration is set to true the event behaves the same as if it is
suppressed by API call. An event suppressed by configuration can not be
activated via API call.
Use case-specific configuration of fault memory, only required events are
Rationale:
visible and usable in ECU.
Use Case: Variant coding
5

51 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04110] SAE J1939 lamp status d

The composite and DTC-specific lamp status of the following lamps shall be
Description: supported: Malfunction Indicator Lamp, Red Stop Lamp, Amber Warning Lamp
and Protect Lamp.
Rationale: Support of SAE J1939-73
Use Case: Diagnostics in HDV, HDOBD
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04111] SAE J1939 Expanded-FreezeFrame d

The composite and DTC-specific lamp status of the following lamps shall be
Description: supported: Malfunction Indicator Lamp, Red Stop Lamp, Amber Warning Lamp
and Protect Lamp.
Rationale: Support of SAE J1939-73
Use Case: Diagnostics in HDV, HDOBD
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260, RS_Main_00420)

52 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04113] Support a set of SAE J1939 DM-messages d

The following DM-messages shall be supported:

Name Description
DM01 Active Diagnostic Trouble Codes
DM02 Previously Active Diagnostic Trouble Codes
DM03 Diagnostic Data Clear/Reset for Previously Active DTCs
DM04 Freeze Frame Parameters
DM05 Diagnostic Readiness 1
DM06 Emission Related Pending DTCs
DM11 Diagnostic Data Clear/Reset for Active DTCs
DM12 Emissions Related Active DTCs
DM13 Stop Start Broadcast
DM19 Calibration Information
Description: DM20 Monitor Performance Ratio SAE J1939-73 Revised SEP2006
DM21 Diagnostic Readiness 2
DM23 Previously Active Emission Related Faults
DM24 SPN Support
DM25 Expanded Freeze Frame
DM26 Diagnostic Readiness 3
DM28 Permanent DTCs
DM29 Regulated DTC Counts (Pending, Permanent, MIL-On, PMIL-On)
DM31 DTC to Lamp Association
DM35 Immediate Fault Status
DM53 Active Service Only DTCs
DM54 Previously Active Service Only DTCs
DM55 Diagnostic Data Clear/Reset for All Service Only DTCs
Rationale: Support of SAE J1939-73
Use Case: Diagnostics in HDV, HD-OBD
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260, RS_Main_00420)

53 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04241] Support for unsupported SAE J1939 DM-messages d

All DM-messages that are not listed in [RS_Diag_04113] shall be supported by

Description:
a generic service.
An application shall be capable of handling DM-messages that are not directly
Rationale: handled by the implementation of the diagnostics module.
Use Case: Handling of memory access or routine control.
AppliesTo: CP
Dependencies: [RS_Diag_04113]
Supporting SAE J1939-73+
Material:

c(RS_Main_00260)
[RS_Diag_04137] Definition of replacement failure d

Upon filtering the storage of failure reports by central conditions (Storage

Condition), it shall be possible to define and store a replacement failure info
Description:
which then can be stored to the event memory. This replacement failure will
represent the actual failure reason.
Rationale: Improvement of failure analysis.
Use Case: –
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04155] Notify applications and BSW modules about updates of event
related data d

The diagnostic in AUTOSAR shall notify other applications / BSW modules

Description:
about updates of the event-related data in the event memory.
Changes to the event related data are done internally while evaluating event
Rationale: information passed from the monitoring application. Third parties interested in
the change of event related data need to get notified.
Use Case: Allow OEM specific reaction on updates of the event related data.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)

54 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04217] Adding the Lamp status pertinent to a specific Fault Event/DTC

available as DemInternalDataClass shall be codified in the same format of DM31
d

when a Fault Event memory entry is coming, the related FreezeFrame includes
the pertinent DTC lamp status with the SPN number for each kind of lamp. In
fact, the format of this data shall also be compliant to the content of the DM31
Description: with the same codification/format and SPNs identification. In other word this
solution would ensure that the user is able to retrieve the pertinent lamp status
as it becomes a memory entry even if the DM31 request is not done in the
same moment.
Rationale: After sales analysis.
Use Case: Provide lamp status per DTC to diagnostic testers.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04165] Triggering of multiple events upon a master event is reported d

The diagnostic in AUTOSAR shall provide the capability to trigger multiple

Description:
events upon an event is reported.
From one unique fault source, multiple events shall be derived and each
Rationale: derived event can trigger an own DTC and event memory entry.
Storing DTCs from one unique source into different event memories without
changing and recompiling the reporting software. A given software can report
Use Case:
event status information and depending on configuration multiple DTCs and
event related data in different fault memories can be stored.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04031] Notify the Function Inhibition Manager (FIM) upon changes
of the event status in order to process them according to the SW components
dependencies d

Control (enable/disable) of functionalities of SW components based on the

Description: following inhibit condition:
- faults
Rationale: Event status information for function inhibition
Use Case: Usage of event status information for function inhibition
AppliesTo: CP
Dependencies: –
5

55 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04221] In-Use-Monitor Performance Ratio indicates how often the OBD
system monitors particular components, compared to the amount of the vehicle
operation d

The diagnostic in AUTOSARs shall provide a means to indicates how often the
OBD system monitors particular components, compared to the amount of the
vehicle operation.This is done through In-Use-Monitor Performance Ratio
Description: (IUMPR). It is defined as the number of times a fault could have been found
(=numerator), divided by the number of times the vehicle operation conditions
have been fulfilled (=denominator) as defined in the respective OBD
regulations.
Rationale: Supporting OBD use cases
Use Case: Calculation of IUMPR for legal regulation
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04223] Support Snapshot Records data pre-storage d

The diagnostic in AUTOSAR shall provide means to applications to immediately

Description: trigger capturing snapshot record data.This captured data shall be stored in the
snapshot record if the trigger condition is fulfilled in a later point in time.
Snapshot record data would always have the data value at a point in time when
Rationale: a trigger occurs which might be too late as the environmental data already has
changed since the first fault occurrence.
Use Case: Capture snapshot record data at the first time the fault occurs.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04250] Support subfunction 0x1A and 0x56 of UDS service 0x19 d

The diagnostic in AUTOSAR shall support subfunction 0x1A and 0x56 of UDS
Description: service 0x19 to retrieve information for emission related DTCs and supported
ECU data.
Rationale: Required to fulfill SAE J1979-2 and enhanced diagnostics.
5

56 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Support of legislated diagnostic requirements and enhanced diagnostic
Use Case:
support.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04252] Support of SAE J1979-2 d

Description: AUTOSAR shall support OBD services according to SAE J1979-2

Legislation requires vehicle manufacturer to report emission related information
Rationale: via diagnostics.
Use Case: Develop emission related ECUs with AUTOSAR.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04253] Support separated DTCs for UDS and OBD based on J1979-2 d

SAE J1979-2 based UDS communication shall report a different 3 byte DTC
Description:
number than for none J1979-2 UDS communication.
A further set of 3 Byte DTCs is required to avoid conflicts with UDS enhanced
Rationale: diagnostics.
Some manufacturers don’t want to fully change to SAE J1979-2 support with
Use Case: UDS and will only support the J1979-2 functionality on the limited UDS subset
defined by J1979-2.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)

57 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04254] Independent CP Software Cluster development d

The diagnostic in AUTOSAR shall support the flexible implementation of

diagnostic capabilities in Application Software Clusters. Hence, widely used
interfaces applicable for Application Software Clusters shall avoid
precompile-time configurability. Configuration parameters adopting to
application dependent behavior shall be post-build configurable. Widely used
interfaces are related to
• UDS Services
– 0x22 ReadDataByIdentifier
Description: – 0x24 ReadScalingDataByIdentifier
– 0x2E WriteDataByIdentifier
– 0x2F InputOutputControlByIdentifier
– 0x31 RoutineControl Supported
• OBD Services
– $01 Request Current Powertrain Diagnostic Data
– $09 Request Vehicle Information
• Diagnostic Monitors
Rationale: -
Change diagnostic related functionality in an Application Software Clusters
Use Case:
without rebuild of the Host Software Clusters
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04255] Support of nested data elements for the DID d

The Dcm shall support the usage of nested data elements for the DID
Description: sender/receiver and RID routine interaction between the Dcm and application
software.
Nested data types are a commonly used case in AUTOSAR application
Rationale: software. Consequently, the AUTOSAR diagnostic stack shall support this case
for the interaction between the Dcm and application software.
The user wants to access a nested data type in a PortPrototype of the
Use Case: application to be used in the description of diagnostic content (e.g. the
definition of a Diagnostic Data Identifier).
AppliesTo: CP
Dependencies: –
Supporting ISO14229-1
Material:

c(RS_Main_00011)

58 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4.2.2.1 DTC and event-related data

[RS_Diag_04162] Parallel fault memory access d

The diagnostic in AUTOSAR shall provide parallel access to the fault memory
Description: to various clients. Each client shall be able to access the fault memory
independent from other clients. Conflicts occurring during parallel access to
shared resources shall be resolved.
Rationale: OEMs require parallel access to diagnostics.
• Support of OBD and UDS in parallel
Use Case: • Software interacting with secondary ECUs in OBD
• Software components accessing event memory data
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04164] Independent event memories for multiple diagnostic server in-
stances (virtual ECUs) d

The diagnostic in AUTOSAR shall provide multiple sets of independent event

Description:
memories that can store information independently from each other.
Rationale: Individual assignment of fault memories to dedicated diagnostic servers.
ECUs with multiple independent diagnostic servers. Common faults of the host
ECU shall be stored in each of the virtual ECU which is affected by such a fault.
Common faults need to be stored in each virtual ECU to ensure that storing
and clearing of fault entries has no or little side-effects with the information
Use Case:
stored in other virtual ECUs.
This use-case assumes that the cost to store a common fault in multiple event
memory entries is accepted because sharing of a single event memory entry
may have unintended side-effects.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00260)

59 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4.2.3 Diagnostic Communication

[RS_Diag_04021] Handling of different diagnostic sessions in parallel d

Handle an established diagnostic communication and a parallel diagnostic

access request in parallel. This is necessary to open a diagnostic access with
Description:
high priority and the controlled shutdown of the established diagnostic access
with low priority.
To prioritize handling of different diagnostic protocols e.g. OBD and normal
Rationale: diagnostic communication as UDS.
An internal vehicle diagnostic tester communication is interrupted by OBD
Use Case: diagnostic access request.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04032] Different diagnostic addresses shall be supported by multiple
(physical) channels d

Modern ECUs contain more than one functionality (e.g. board computer,
instrument cluster). Each functionality shall be addressable by a diagnostic tool
Description:
with a different diagnostic address. This does not imply that those multiple
requests are allowed in parallel.
Rationale: High flexibility and granularity for addressing of applications
At the service (garage) a fault symptom is based on functionality. The service
Use Case:
only wants to address this functionality.
AppliesTo: CP
Dependencies: [RS_Diag_04021] Switch diagnostic communication access
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04024] Access and handle specific data elements and data element
groups if requested by an external scan tool d

The diagnostic in AUTOSAR shall provide interfaces for applications to access

Description: diagnostic data and to process diagnostic services. The size of a diagnostic
data element is derived by the interface or provided as an attribute of the API
call itself.
Rationale: Optimized usage of resources
Use Case: Transfer environmental / FreezeFrame data of the diagnostic in AUTOSAR.
AppliesTo: CP
Dependencies: –
5

60 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04019] Provide confirmation after transmit diagnostic responses to
the application d

Diagnostic in AUTOSAR shall notify applications about successful or failed

Description:
transmission of diagnostic responses.
Provide application a mean to get notified on transmission results. Some
operations shall only be started after the transmission. Without this notification
Rationale: an application will have no knowledge when to start an operation depending on
a previous transmission. Service response confirmation is defined by ISO
14229-1 v.2013.
E.g.reset function. The ECU shall only be reset if the positive response was
Use Case:
sent on the bus.
AppliesTo: CP
Dependencies:
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011)
[RS_Diag_04121] Provide the handling of service DynamicallyDefineDataIdenti-
fier according to ISO 14229-1 d

The diagnostic in AUTOSAR shall provide the handling of service

Description:
DynamicallyDefineDataIdentifier according to ISO 14229-1 v.2013.
Rationale: Standardized ISO 14229-1 v.2013 behavior
Use Case: –
AppliesTo: CP
Dependencies: –
Supporting ISO14229-1 v.2013
Material:

c(RS_Main_00011, RS_Main_00260)
[RS_Diag_04153] Support generic connections d

Diagnostics shall support generic connections. Addressed information is then

Description:
using MetaData.
Rationale: Channel and connection configuration optimization through the layers.
Use Case: Limit the request execution due to vehicle- or ECU states/-conditions.
AppliesTo: CP
5

61 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
Generic connections are supported for CAN diagnostics using normal fixed or
mixed 29 bit addressing formats according to ISO15765-2. Depending on the
Dependencies:
actual layout of the CAN IDs, generic connections could also be used for
extended or normal and mixed 11 bit addressing formats.
Supporting –
Material:

c(RS_Main_00260)
[RS_Diag_04011] Provide diagnostic state information to applications d

Applications need to know about the actual session and security state, because
Description: it is not predictable if the information’s lead to a different functional diagnostic
behavior.
Rationale: Functional requirement
With the diagnostic session which the garage is using, it is allowed to switch
between different sets of parameters.
Use Case: With an enhanced diagnostic session which could be used in development and
a corresponding security level, it is allowed to change the data within the set of
parameters.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011)
[RS_Diag_04003] Network independent design d

All network (CAN, LIN, FlexRay, MOST, Ethernet) dependent parts shall be
Description: done outside the diagnostic in AUTOSAR. That means that all interfaces to the
transport protocol modules shall be network independent.
The diagnostic in AUTOSAR describes only the services for communication
Rationale: and the behavior of network is out of scope.
Highest granularity and best option to adapt upcoming networks.
The diagnostic in AUTOSAR has to be network independent. The interface to
Use Case:
the transport protocol shall be network independent.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011, RS_Main_00260)

62 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04243] Update of constant parameters through diagnostics d

Almost constant parameters shall be updatable via diagnostics. Reading and

Description:
writing those parameters shall avoid a RAM copy of the data.
The size of coding parameter is increasing dramatically. The current FEE
Rationale: concepts require conceptually a RAM copy of the data. This RAM copy shall be
avoided.
Use Case: Coding parameter
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011, RS_Main_00260)
[RS_Diag_04247] Support of UDS service DynamicallyDefineDataIdentifier
(0x2C) with subfunction 0x02 (defineByMemoryAddress) d

The diagnostic in AUTOSAR shall support UDS service

Description: DynamicallyDefineDataIdentifier (0x2C) with subfunction 0x02
(defineByMemoryAddress) according to ISO 14229-1.
UDS defines this service to allow the client to dynamically define a data
Rationale: identifier based on known and individual memory addresses at a later point in
time.
Read operations for tailored data identifier that are build out of a collection of
Use Case: parts or full content of existing data identifiers with UDS service 0x22/0x2A.
AppliesTo: CP
Dependencies: –
Supporting –
Material:

c(RS_Main_00011, RS_Main_00260)
[RS_Diag_04015] Timing handling according to ISO14229-2 d

In ISO14229-2 timing handling for physical and functional communication and

Description: error reaction is described. The diagnostic in AUTOSAR shall work according
this specification. Timing parameters shall be configurable (see dependencies).
Ensure a steady and save communication link and guarantee specified timing
Rationale:
conditions.
Use Case: Optimizing of timing for high performance during reprogramming.
AppliesTo: CP
Dependencies: [RS_Diag_04059] Configuration of timing parameter
Supporting ISO14229-2
Material:

c(RS_Main_00011)

63 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4.2.4 Function Inhibition Manager (FIM)

The specification of Software requirements of the function inhibition manager is not a

part of this specification. For details, please refer to the AUTOSAR_FIM_SRS.

4.3 Diagnostic requirements for the Adaptive Platform

[RS_Diag_04166] Several tester conversations in parallel with assigned priorities
d

The diagnostic in AUTOSAR shall generally support a configurable amount of

tester conversations/connections in parallel. Per tester connection, a priority
Description:
shall be configurable. The priority is assigned to the tester address (SA of the
UDS request), which identifies the connection.
ECUs in the Adaptive Platform generally have enough resources to handle
Rationale:
multiple tester conversations in parallel.
AppliesTo: AP
Dependencies: –
Support for vehicle internal and external testers in parallel, which can not be
Use Case:
easily synchronized.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04209] Pseudo parallel client interaction according to ISO d

The diagnostic in AUTOSAR shall support the parallelism defined by the ISO as
Description:
pseudo parallel concept, which is defined in ISO 14229-1 under Figure J.2.
AppliesTo: AP
Dependencies: –
Support of scenarios, where testers in parallel is only allowed, when in default
Use Case:
session.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00011)
[RS_Diag_04167] Conversation preemption/abortion d

The diagnostic in AUTOSAR shall generally support the preemption of a tester

conversation in case all configured tester connections are currently active and a
Description: new connection of a tester with higher priority than an existing one takes place,
it shall abort the lowest priority conversation and accept the new
connection/conversation.
5

64 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

4
A ECU will have limited resources for parallel processing of diagnostic requests
Rationale: and different requests will have different priorities therefore the need for
abortion.
AppliesTo: AP
Dependencies: –
Support for vehicle internal and external testers in parallel, which can not be
Use Case:
easily synchronized.
Supporting ISO 14229-1
Material:

c(RS_Main_00260)
[RS_Diag_04168] Adding of user-defined transport layers d

The diagnostic in AUTOSAR shall support adding of user-defined transport

Description:
layers.
Although the Adaptive Platform starts out with Ethernet support, later extension
to other networks (CAN, FlexRay) should already be prepared. Additionally
Rationale: there is at least one OEM, which has its own DoIP implementation, which
differs from ISO 13400. It should be possible to integrate this DoIP
implementation with manageable effort/costs.
AppliesTo: AP
Dependencies: –
Use Case: Plugability of UDS transport layers, to support different networks.

c(RS_Main_00260)
[RS_Diag_04169] Provide an interface for external UDS service processors. d

For all UDS services, which are NOT processed/implemented internally by

diagnostic in AUTOSAR (either by configuration or generally not supported
Description:
internally), but by external service processors, the diagnostic in AUTOSAR has
to delegate the processing to the external application.
The majority of diagnostic services is implemented by the application, where
Rationale: the diagnostic in AUTOSAR has to delegate the service processing to.

AppliesTo: AP
Dependencies: [RS_Diag_04097]
Use Case: Service processing by software components.
Supporting ISO 14229-1
Material:

c(RS_Main_00260, RS_Main_00420)

65 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04170] Provide connection specific meta information to external ser-

vice processors d

The diagnostic in AUTOSAR shall provide connection specific meta-information

to the external service processor, which is processing the UDS service request.
At least DoIP shall be supported and the meta-information shall contain
Description:
Src-IP-Adr/Port and Target-IP-Adr/Port of the request. The meta-information
should be designed, that it can later easily extended to also cover connection
information of other network technologies (like CAN, Flexray).
Sometimes the reaction of service processor implementations on a UDS
Rationale:
request depend on the connection properties of the tester.
Dependencies: [RS_Diag_04169]
Use Case: Flexibility for service processor implementations.
AppliesTo: AP
Dependencies: –

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04171] Synchronous and asynchronous interaction with external ser-
vice processors d

The diagnostic in AUTOSAR shall support both types of interaction:

• Calling a service processor synchronously, which means a blocking call
until the service processor returns the final result (pos./neg. response,
optional out parameters).
Description:
• Calling a service processor asynchronously, which means a call to the
service processor, where the service processor returns, that the job is
not yet finished and later reports back to diagnostic in AUTOSAR via a
separate callback, that the service processing has finished.
For long running service processing, which delegate the processing to own
Rationale: worker threads, the asynchronous callback model is more efficient, while for
simple service processors the strict synchronous model is easier to implement.
AppliesTo: AP
Dependencies: [RS_Diag_04169]
Use Case: Flexibility for service processor implementations.

c(RS_Main_00260, RS_Main_00420)

66 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04173] Different signature types, when delegating processing of UDS

service to the application d

The diagnostic in AUTOSAR shall support the following signatures, when

delegating processing of UDS service to the application:
• Untyped interface, where the entire payload including SID and
Description: sub-service is given as a byte array to service processors
• Typed interface per SID, sub-service and data element, where a
mapping from the UDS parameters/data stream to datatypes is
described in the configuration.
Depending on the use case/complexity of the UDS service and its parameters,
it is much more efficient to do the parsing/interpretation in the implementation
of the service processor. On the other hand, there are use cases, where the
Rationale: description of mapping from UDS data stream to interface type has the benefit,
that the service processor implementation may stay unchanged, where the
mapping description may be adapted to an altered on the wire representation.
AppliesTo: AP
Dependencies: [RS_Diag_04169]
Use Case: Flexibility for service processor implementations.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04174] Provide SA and TA to external service processors d

The diagnostic in AUTOSAR shall provide source and target address to the
Description:
external service processor, which is processing the UDS service request.
Sometimes the reaction of service processor implementations on a UDS
Rationale: request depend on the tester (SA) or on the target.
AppliesTo: AP
Dependencies: [RS_Diag_04169]
Use Case: Flexibility for service processor implementations.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04216] Support for multiple Diagnostic Server Instances d

The Diagnostics in AUTOSAR shall be able to handle multiple Diagnostic

Server Instances. Each Diagnostic Server Instance shall be addressable by its
Description: own set of target address and they shall be almost independent of each other.
Exceptions like EcuReset needs to be coordinated between the server
instances.
Software on AP is grouped in so called SoftwareClusters, and each cluster
Rationale: shall be diagnosed on its own.
AppliesTo: AP
Dependencies: –
Multiple SoftwareClusters deployed on single AP and each SoftwareCluster is
Use Case: diagnosed separately.

c(RS_Main_00260, RS_Main_00420)

67 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04251] Support of UDS service 0x29 (Authentication) d

Diagnostics in AUTOSAR shall support the ISO 14229-1:2020 service 0x29

Description: Authentication with sub-functions for "Authentication with PKI Certificate
Exchange (APCE)" to grant access to diagnostic services.
The authentication service provides a standardized way in authenticating a
Rationale: tester and ECU and grant access to diagnostic services depending on the
certificate content.
AppliesTo: AP
Dependencies: –
A repair shop diagnostic tester authenticates with an ECU to gain access to
Use Case: diagnostic services that are explicitly allowed to be executed for a repair shop.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04256]{DRAFT} Support of SOVD d

Diagnostics within AUTOSAR shall support an SOVD endpoint according the

Description:
ASAM specification "‘SOVD - Service Oriented Vehicle Diagnostics V1.0.0"‘.
Rationale: Provide vehicle access for backends
AppliesTo: AP
Dependencies: ISO14229-1
Use Case: Modernized diagnostic approach in the automotive industry

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04257]{DRAFT} Capability Description d

Diagnostics in AUTOSAR shall support the "‘API Methods for Access to

Description:
Capability Description Content"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: SOVD is a self-describing protocol

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04258]{DRAFT} Discovering of Entities and Resources d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Discovering of
Entities and Resources"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
A client to traverse the topology to find out, which methods can be used for
Use Case:
which resources.

c(RS_Main_00260, RS_Main_00420)

68 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04259]{DRAFT} Fault Memory Access d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Fault Handling"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Providing fault memory data

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04260]{DRAFT} Read / Write Access d

Diagnostics in AUTOSAR shall support the "‘API methods for data ressource
Description:
read / write access"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Reading and writing various kinds of data

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04261]{DRAFT} Configuration Access d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Configuration"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Components and Apps need to be configured to a specific environment, e.g.,
Use Case: vehicle equipment, country, customer demand, variant coding, etc.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04262]{DRAFT} Control of Operations d

Diagnostics in AUTOSAR shall support the "‘API Methods for Control of

Operations"‘. The following limitations in Operation capabilities related to SOVD
Description: methods: I/O control adjustments are not supported for the SOVD server in
Adaptive Platforms, as the UDS service for I/O control is also not supported,
yet.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Remote procedure calls and adjustment of values

c(RS_Main_00260, RS_Main_00420)

69 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04263]{DRAFT} Support of Target Modes d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Support of Target
Modes"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Controlling and preparing states/modes of target entities

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04264]{DRAFT} SOVD specific Locking/Semaphore mechanism d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Locking"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Gain exclusive access to a single client for specific resources

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04265]{DRAFT} Software Update d

Diagnostics in AUTOSAR shall support the "‘API Methods for Software

Description:
Update"‘.
Rationale: Optional part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: SOVD approach to update software

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04266]{DRAFT} Bulk data d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Handling of
bulk-data"‘.
Rationale: Optional part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Handling of larger bulk data like kernel-dump files

c(RS_Main_00260, RS_Main_00420)

70 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

[RS_Diag_04267]{DRAFT} Logging d

Description: Diagnostics in AUTOSAR shall support the "‘API Methods for Logging"‘.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Aggregation of logging information

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04268]{DRAFT} Authentication d

Diagnostics in AUTOSAR shall support the "‘Authentication of SOVD clients"‘

AUTOSAR shall mandate a security solution based on OAuth as defined in the
Description:
chapter 6.15 Authentication of SOVD clients. SOVD does not mandate
compared to AUTOSAR this solution as this chapter is only informative.
Rationale: Essential part of the SOVD protocol
AppliesTo: AP
Dependencies: –
Enabling authorization and validation process to protect the resources of any
Use Case: accessible entity in a car against misuse.

c(RS_Main_00260, RS_Main_00420)
[RS_Diag_04269]{DRAFT} SOVD 2 UDS Adapter d

Description: Diagnostics in AUTOSAR shall support the "‘Classic Diagnostic Adapter"‘.

Rationale: Optional part of SOVD protocol
AppliesTo: AP
Dependencies: –
Use Case: Adapter to access UDS-based ECUs via SOVD

c(RS_Main_00260, RS_Main_00420)

4.4 Configuration

71 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

5 Requirements Tracing
The following tables reference the requirements specified in [1] and links to the fulfill-
ment of these. Please note that if column ”Satisfied by” is empty for a specific require-
ment this means that this requirement is not fulfilled by this document.

Requirement Description Satisfied by

[RS_Main_00011] Mechanisms for Reliable [RS_Diag_04003] [RS_Diag_04005]
Systems [RS_Diag_04006] [RS_Diag_04011]
[RS_Diag_04015] [RS_Diag_04016]
[RS_Diag_04019] [RS_Diag_04020]
[RS_Diag_04021] [RS_Diag_04024]
[RS_Diag_04031] [RS_Diag_04032]
[RS_Diag_04033] [RS_Diag_04057]
[RS_Diag_04058] [RS_Diag_04059]
[RS_Diag_04063] [RS_Diag_04064]
[RS_Diag_04107] [RS_Diag_04119]
[RS_Diag_04120] [RS_Diag_04121]
[RS_Diag_04135] [RS_Diag_04147]
[RS_Diag_04156] [RS_Diag_04157]
[RS_Diag_04159] [RS_Diag_04162]
[RS_Diag_04166] [RS_Diag_04189]
[RS_Diag_04190] [RS_Diag_04195]
[RS_Diag_04198] [RS_Diag_04199]
[RS_Diag_04205] [RS_Diag_04206]
[RS_Diag_04208] [RS_Diag_04209]
[RS_Diag_04211] [RS_Diag_04218]
[RS_Diag_04220] [RS_Diag_04221]
[RS_Diag_04222] [RS_Diag_04223]
[RS_Diag_04224] [RS_Diag_04243]
[RS_Diag_04247] [RS_Diag_04250]
[RS_Diag_04252] [RS_Diag_04253]
[RS_Diag_04254] [RS_Diag_04255]
[RS_Main_00060] Standardized Application [RS_Diag_04182] [RS_Diag_04183]
Communication Interface [RS_Diag_04185] [RS_Diag_04186]
[RS_Diag_04194] [RS_Diag_04204]
[RS_Main_00130] Hardware Abstraction Layer [RS_Diag_04077]
[RS_Main_00170] AUTOSAR shall provide secure [RS_Diag_04230] [RS_Diag_04232]
access to ECU data and [RS_Diag_04233] [RS_Diag_04234]
services [RS_Diag_04235] [RS_Diag_04236]
[RS_Diag_04237] [RS_Diag_04238]
[RS_Diag_04239] [RS_Diag_04240]
[RS_Main_00260] Runtime Diagnostics Means [RS_Diag_04002] [RS_Diag_04003]
[RS_Diag_04059] [RS_Diag_04067]
[RS_Diag_04068] [RS_Diag_04071]
[RS_Diag_04091] [RS_Diag_04093]
[RS_Diag_04097] [RS_Diag_04098]
[RS_Diag_04110] [RS_Diag_04111]
[RS_Diag_04112] [RS_Diag_04113]
[RS_Diag_04115] [RS_Diag_04117]
[RS_Diag_04118] [RS_Diag_04120]
[RS_Diag_04121] [RS_Diag_04123]
[RS_Diag_04124] [RS_Diag_04126]
[RS_Diag_04127] [RS_Diag_04129]

72 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

Requirement Description Satisfied by

[RS_Diag_04131] [RS_Diag_04133]
[RS_Diag_04136] [RS_Diag_04137]
[RS_Diag_04139] [RS_Diag_04140]
[RS_Diag_04147] [RS_Diag_04148]
[RS_Diag_04150] [RS_Diag_04151]
[RS_Diag_04153] [RS_Diag_04155]
[RS_Diag_04160] [RS_Diag_04161]
[RS_Diag_04163] [RS_Diag_04164]
[RS_Diag_04165] [RS_Diag_04166]
[RS_Diag_04167] [RS_Diag_04168]
[RS_Diag_04169] [RS_Diag_04170]
[RS_Diag_04171] [RS_Diag_04172]
[RS_Diag_04173] [RS_Diag_04174]
[RS_Diag_04177] [RS_Diag_04178]
[RS_Diag_04179] [RS_Diag_04180]
[RS_Diag_04189] [RS_Diag_04190]
[RS_Diag_04192] [RS_Diag_04194]
[RS_Diag_04195] [RS_Diag_04196]
[RS_Diag_04197] [RS_Diag_04198]
[RS_Diag_04199] [RS_Diag_04200]
[RS_Diag_04201] [RS_Diag_04203]
[RS_Diag_04205] [RS_Diag_04206]
[RS_Diag_04208] [RS_Diag_04209]
[RS_Diag_04214] [RS_Diag_04215]
[RS_Diag_04216] [RS_Diag_04217]
[RS_Diag_04218] [RS_Diag_04219]
[RS_Diag_04222] [RS_Diag_04224]
[RS_Diag_04225] [RS_Diag_04226]
[RS_Diag_04227] [RS_Diag_04228]
[RS_Diag_04241] [RS_Diag_04242]
[RS_Diag_04243] [RS_Diag_04244]
[RS_Diag_04245] [RS_Diag_04247]
[RS_Diag_04248] [RS_Diag_04249]
[RS_Diag_04251] [RS_Diag_04256]
[RS_Diag_04257] [RS_Diag_04258]
[RS_Diag_04259] [RS_Diag_04260]
[RS_Diag_04261] [RS_Diag_04262]
[RS_Diag_04263] [RS_Diag_04264]
[RS_Diag_04265] [RS_Diag_04266]
[RS_Diag_04267] [RS_Diag_04268]
[RS_Diag_04269]
[RS_Main_00420] AUTOSAR shall use established [RS_Diag_04067] [RS_Diag_04068]
software standards and [RS_Diag_04097] [RS_Diag_04105]
consolidate de-facto standards [RS_Diag_04109] [RS_Diag_04110]
for basic software functionality [RS_Diag_04111] [RS_Diag_04113]
[RS_Diag_04124] [RS_Diag_04125]
[RS_Diag_04169] [RS_Diag_04170]
[RS_Diag_04171] [RS_Diag_04172]
[RS_Diag_04173] [RS_Diag_04174]
[RS_Diag_04192] [RS_Diag_04204]
[RS_Diag_04216] [RS_Diag_04219]
[RS_Diag_04225] [RS_Diag_04246]
[RS_Diag_04251] [RS_Diag_04256]

73 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

Requirement Description Satisfied by

[RS_Diag_04257] [RS_Diag_04258]
[RS_Diag_04259] [RS_Diag_04260]
[RS_Diag_04261] [RS_Diag_04262]
[RS_Diag_04263] [RS_Diag_04264]
[RS_Diag_04265] [RS_Diag_04266]
[RS_Diag_04267] [RS_Diag_04268]
[RS_Diag_04269]
[RS_Main_00440] AUTOSAR shall standardize [RS_Diag_04077]
access to non-volatile memory

74 of 75 Document ID 4: AUTOSAR_RS_Diagnostics
 Requirements on Diagnostics
AUTOSAR FO R22-11

6 References

[1] Main Requirements

AUTOSAR_RS_Main

6.1 Deliverables of AUTOSAR

1. General Requirements of Basic Software Modules:
AUTOSAR_SRS_BSWGeneral.pdf
2. Specification of the Virtual Functional Bus : AUTOSAR_EXP_VFB.pdf
3. Software Standardization Template : AUTOSAR_TPS_StandardizationTemplate.pdf

6.2 Related standards and norms

6.2.1 ITEA-EAST

1. D1.5-General Architecture; ITEAEAST-EEA, Version 1.0; chapter 3, page 72 et

seq.
2. D2.1-Embedded Basic Software Structure Requirements; ITEAEAST-EEA, Ver-
sion 1.0 or higher
3. D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.

6.2.2 ISO

1. ISO 14229-1 Unified diagnostic services (UDS) Part 1: Specification and Re-
quirements (v.2013)
2. ISO 15031-5 Communication between vehicle and external equipment for emis-
sions related diagnostics Part 5: Emissions related diagnostic services (2005-01-
13)
3. ISO 15765-3 Diagnostics on controller area network (CAN) Part 3: Implementa-
tion of unified diagnostic services (UDS on CAN) (2004-10-06)
4. ISO 15765-4 Diagnostics on controller area network (CAN) Part 4: Requirements
for emissions-related systems (2005-01-04)

75 of 75 Document ID 4: AUTOSAR_RS_Diagnostics