Autosar Srs Diagnostic

Requirements on Diagnostic
V2.1.1
R3.1 Rev 0001
Document Title
Document Owner
Document Responsibility
Document Identification No
24.07.2008
AUTOSAR GbR
AUTOSAR GbR
004
Auxiliary
Document Version
Document Status
Part of Release
Revision
2.1.1
Final
3.1
0001
Document Change History

Date
24.07.2008
Version
2.1.1
Changed by
AUTOSAR
Administration
AUTOSAR
Administration
24.07.2008
2.1.0
31.10.2007
2.0.3
AUTOSAR
Administration
24.01.2007
2.0.2
28.11.2006
2.0.1
06.04.2006
2.0.0
30.06.2005
1.0.0
AUTOSAR
Administration
AUTOSAR
Administration
AUTOSAR
Administration
AUTOSAR
Administration
Change Description
Layout adaptations
Remove requirement BSW04062
Added requirement BSW04082 for
OBDII support
Legal disclaimer revised
Document meta information
extended
Small layout adaptations made
Advice for users revised
Revision Information added
Legal Disclaimer revised
Minor formal changes
Initial Release
Document ID 004: AUTOSAR_SRS_Diagnosic
1 of 29
- AUTOSAR confidential -
V2.1.1
R3.1 Rev 0001
Page left intentionally blank
2 of 29
V2.1.1
R3.1 Rev 0001
Disclaimer
This document of a specification as released by the AUTOSAR Development
Partnership is intended for the purpose of information only. The commercial
exploitation of material contained in this specification requires membership of the
AUTOSAR Development Partnership or an agreement with the AUTOSAR
Development Partnership. The AUTOSAR Development Partnership will not be liable
for any use of this specification. Following the completion of the development of the
AUTOSAR specifications commercial exploitation licenses will be made available to
end users by way of written License Agreement only.
No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher." The word AUTOSAR and the AUTOSAR logo
are registered trademarks.
Copyright 2004-2008 AUTOSAR Development Partnership. All rights reserved.
Advice to users of AUTOSAR Specification Documents:

AUTOSAR Specification Documents may contain exemplary items (exemplary
reference models, "use cases", and/or references to exemplary technical solutions,
devices, processes or software).
Any such exemplary items are contained in the Specification Documents for
illustration purposes only, and they themselves are not part of the AUTOSAR
Standard. Neither their presence in such Specification Documents, nor any later
documentation of AUTOSAR conformance of products actually implementing such
exemplary items, imply that intellectual property rights covering such exemplary
items are licensed under the same rules as applicable to the AUTOSAR Standard.
3 of 29
V2.1.1
R3.1 Rev 0001
Table of Contents
1
Scope of this document ....................................................................................... 6
How to read this document.................................................................................. 7

2.1
2.2
Conventions used......................................................................................... 7
Requirements structure ................................................................................ 8
Acronyms and abbreviations ............................................................................... 9
Requirement Specification................................................................................. 10
4.1
Functional Requirements ........................................................................... 10
4.1.1
General ............................................................................................... 10
4.1.1.1
[BSW04010] Interface between Diagnostic service handling and
Diagnostic event (error) management............................................................ 10
4.1.1.2
[BSW04082] Support of ISO15031-5 and SAE J1979 ................. 10
4.1.2
Diagnostic Event Manager (DEM)....................................................... 11
4.1.2.1
[BSW04002] Basic SW Module for Diagnostic event (error)
management.................................................................................................. 11
4.1.2.2
[BSW04057] Classification of event ............................................. 11
4.1.2.3
[BSW04061] Distinction between different function groups.......... 12
4.1.2.4
[BSW04063] Single Event ID for each monitoring path................ 12
4.1.2.5
[BSW04065] Clearing of events or event groups ......................... 12
4.1.2.6
[BSW04066] Provision of a Secondary Event Memory.............. 13
4.1.2.7
[BSW04058] Support deletion and reading services for Secondary
Event Memory .............................................................................................. 13
4.1.2.8
[BSW04067] Counting and evaluation of events according to ISO
14229-1 DTCStatusMask............................................................................... 14
4.1.2.9
[BSW04068] Standardized Event forget/unlearn counting ........... 14
4.1.2.10 [BSW04069] DEM System status indication ................................ 14
4.1.2.11 [BSW04070] Event occurrence order definition ......................... 15
4.1.2.12 [BSW04071] Event importance definition..................................... 15
4.1.2.13 [BSW04072] Extended event information .................................... 15
4.1.2.14 [BSW04073] Event combination and compression ...................... 16
4.1.2.15 [BSW04074] Event related environmental data ......................... 16
4.1.2.16 [BSW04075] Event and DTC assignment .................................... 16
4.1.2.17 [BSW04076] System Cycle definition........................................... 17
4.1.2.18 Interface and API ......................................................................... 17
4.1.3
Diagnostic communication management (DCM) ................................. 19
4.1.3.1
[BSW04007] Provide Diagnostic service handling ....................... 19
4.1.3.2
[BSW04021] Switch diagnostic communication access ............... 19
4.1.3.3
[BSW04032] Support of different diagnostic addresses ............... 20
4.1.3.4
[BSW04080] Support multi-channel capability for diagnostic
communication............................................................................................... 20
4.1.3.5
Supported diagnostic Services..................................................... 21
4.1.3.6
Timing Requirements ................................................................... 24
4.1.3.7
Resource Usage .......................................................................... 24
4.1.3.8
Interface and API ......................................................................... 25
4.1.4
Configuration....................................................................................... 26
4 of 29
V2.1.1
R3.1 Rev 0001
4.1.4.1
[BSW04059] Configuration of timing parameter........................... 26
4.1.4.2
[BSW04024] Configurable size of transferred data ...................... 27
4.1.4.3
[BSW04064] Event buffer shall be configurable concerning size . 27
4.2
Non-Functional Requirements (Qualities) .................................................. 28
4.3
Output for other Modules............................................................................ 28
4.3.1
Requirements on Services (Services Layer) ....................................... 28
4.3.2
Requirements on RTE......................................................................... 28
4.3.3
Requirements on ECU Abstraction Layer ........................................... 28
5
References ........................................................................................................ 29
5.1
Deliverables of AUTOSAR ......................................................................... 29
5.2
Related standards and norms .................................................................... 29
5.2.1
ITEA-EAST.......................................................................................... 29
5.2.2
ISO...................................................................................................... 29
5 of 29
V2.1.1
R3.1 Rev 0001
1 Scope of this document

The goal of AUTOSAR WP4.2.2.1.4 and this document is to define to what extent
elements of the diagnostic basic software have to be configurable and what
preliminaries they shall comply with to meet the tailoring requirements. The handling
of the legislated OBD and enhanced Diagnostics shall also be achieved.
As far as possible the set of diagnostic basic software elements should consist of
already existing elements of modules of automotive software. Only in case of good
reasons new elements of basic software should be part of the set.
If such the definition of these new elements is not part of this work package.
Nevertheless the information about basic software elements additionally required
shall be given to related work groups.
Constraints
First scope for specification of requirements on basic software modules are systems
which are not safety relevant. For implementation of the basic software modules in
safety relevant systems, it shall be checked if additional requirements are necessary.
For this document we refer to ISO 15031-5. The equivalent SAEJ1979 is not
mentioned explicitly but is covered accordingly.
6 of 29
V2.1.1
R3.1 Rev 0001
2 How to read this document

Each requirement has its unique identifier starting with the prefix BSW (for Basic
Software). For any review annotations, remarks or questions please refer to this
unique ID rather than chapter or page numbers!
2.1 Conventions used

In requirements, the following specific semantics are used (taken from Request for
Comment RFC 2119 from the Internet Engineering Task Force IETF)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. 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 behavior 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
optional. One vendor may choose to include the item because a particular
marketplace 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 include a particular option, MUST be prepared to interoperate
with another implementation, which does include the option, though perhaps
with reduced functionality. In the same vein an implementation, which does
include a particular option, MUST be prepared to interoperate with another
implementation, which does not include the option (except, of course, for the
feature the option provides.)
7 of 29
V2.1.1
R3.1 Rev 0001
2.2 Requirements structure

Each module specific chapter contains a short functional description of the Basic
Software Module. Requirements of the same kind within each chapter are grouped
under the following headlines (where applicable):
Functional Requirements:
- Configuration (which elements of the module need to be configurable)
- Initialisation
- Normal Operation
- Shutdown Operation
- Fault Operation
- ...
Non-Functional Requirements:
- Timing Requirements
- Resource Usage
- Usability
- Output for other WPs (e.g. Description Templates, Tooling,...)
- ...
8 of 29
V2.1.1
R3.1 Rev 0001
3 Acronyms and abbreviations

Acronym:
Description:
External diagnostic tool
It is a device which is NOT permanently connected within the vehicle

communication network. This device could be connected to the vehicle
for various purposes, as e.g.
development
manufacturing
service (garage)
Know devices are e.g.
a diagnostic tester
an OBD scan tool
Internal diagnostic tool
The external diagnostic tool is to be connected by a mechanic to

gather information from inside the car.
It is a device/ECU which could be connected permanently within the
vehicle communication network. The purpose of this device/ECU could
be a functionality as e.g.
advanced event tracking
advanced analysiss
for service mechanics.
The behavior of the device/ECU could be the same as if it is an
external diagnostic tool.
AUTOSAR application
Monitoring path
Event
Diagnostic test results
The meaning of internal diagnostic tool is NOT that it is included in

each ECU as a AUTOSAR SW-Component.
A SW-application above the RTE which is using the APIs defined by
DCM and DEM
A monitoring path represents a diagnostic symptom and it is assigned
to a unique event ID.
In case of the use of the term Event a Diagnostic event is meant.
De-bounced and qualified test result provided by a monitoring function.
9 of 29
V2.1.1
R3.1 Rev 0001
4 Requirement Specification
4.1 Functional Requirements
4.1.1 General
4.1.1.1 [BSW04010] Interface between Diagnostic service handling and
Diagnostic event (error) management
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
Supporting Material:
WP4.2.2.1.4
21.7.2004
DEM and DCM shall ensure interaction in order to fulfill ISO 14229-1 and
15031-5
New
High
The interface between the Diagnostic Service Handling (DCM) and the
Diagnostic Event (error) Management(DEM) shall ensure a interaction
according to the ISO14229-1. The DCM shall use the interface provided by
the DEM to process the required diagnostic service send by a diagnostic
tester.
ISO14229-1
Improved fault and event tracking and analysis for Service, assembly line,
OBD-SCAN-Tool
--ISO14229-1
4.1.1.2 [BSW04082] Support of ISO15031-5 and SAE J1979

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WPII-2.1.4
27.03.2008
The diagnostic modules DCM and DEM shall provide standardized
interfaces to support OBD services as defined in ISO15031-5 and SAE
J1979.
New
High
The DCM and the DEM provide interface to support OBD services $01 to
$0A to access Parameter Identifiers (PIDs), Diagnostic Test Results and
further OBDII specific data.
--Configuration
---
10 of 29
V2.1.1
R3.1 Rev 0001
4.1.2 Diagnostic Event Manager (DEM)
4.1.2.1 [BSW04002] Basic SW Module for Diagnostic event (error) management
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The Diagnostic event (error) management shall be established as Basic SW
Module.
New
High
The Diagnostic event (error) management shall be a Basic SW Module
described in the Diagnostic WP.
Diagnostic event (error) management is out of scope for Mode Management
SW Architecture
Improved fault and event tracking and analysis for Service, assembly line,
OBD-SCAN-Tool
----
4.1.2.2 [BSW04057] Classification of event

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
17.06.2004
The DEM shall support a classification of events for series production, OBD
and expert usage.
New
High
The DEM 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.
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 stored in the DET.
Therefore, a special DET API shall be used which is not provided by the
DEM.
After sales analysis
Distinction between service station relevant and after sales relevant events.
----
11 of 29
V2.1.1
R3.1 Rev 0001
4.1.2.3 [BSW04061] Distinction between different function groups
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
The DEM shall provide mechanisms to distinguish between different
applications.
New
High
The DEM shall process event information of different applications, i.e.
Software components.
Unique Event IDs in DEM
Distinction between different applications using the same DEM by their
application function group in case of merged applications on one single
ECU.
----
4.1.2.4 [BSW04063] Single Event ID for each monitoring path

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
The DEM shall process a dedicated Event ID for each monitoring path.
New
High
For the internal administration the DEM needs a unique identification of each
monitoring path. This identification shall be handled via an Event ID value
(Integer).
Unique fault identification which can be used for enhanced debugging
----
4.1.2.5 [BSW04065] Clearing of events or event groups

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
WP4.2.2.1.4
03.8.2004
The DEM and DCM shall process the deletion of events or event groups.
New
High
The DEM and DCM shall process the deletion of events or event groups
according to ISO14229 AnnexD1 and ISO15031-5.
ISO 14229, ISO15031-5
Single Event deletion
a) Support of mechanics which can follow step by step (DTC by DTC)
the repair process
Event Group deletion:
a) Support of mechanics who can delete areas of faults which are
subsequent faults of the first one.
b) OBD faults
[BSW111], [BSW113]
12 of 29
V2.1.1
R3.1 Rev 0001
Conflicts:
---
4.1.2.6 [BSW04066] Provision of a Secondary Event Memory

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
The DEM shall support the distinction of Primary and Secondary Event
Memory.
New
High
Provision of a Secondary Event Memory is optional and for internal usage by
OEM and supplier, e.g. only used for development and product
improvements.
a) The service station workers have only access to the Primary
Event Memory
b) The development departments of the OEMs and Suppliers have
access to the Primary Event Memory and Secondary Event
Memory
The secondary event memory allows storage of development events. It is not
a trace tool.
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 the faults or may not need to know if there are more detailed root
causes for an event or fault
----
4.1.2.7 [BSW04058] Support deletion and reading services for Secondary

Event Memory
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
Deletion and reading services shall be supported for Secondary Event
Memory.
New
High
The DEM shall support event deletion and reading services separately for
Primary and Secondary Event Memory.
The development departments of the OEMs and Suppliers need as much as
possible deeper fault/event analysis although the mechanics may have
deleted the faults or may not need to know if there are more detailed root
causes for an event or fault.
----
13 of 29
V2.1.1
R3.1 Rev 0001
4.1.2.8 [BSW04067] Counting and evaluation of events according to ISO 142291 DTCStatusMask
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
The DCM and DEM shall provide the diagnostic status information according
to the DTCStatusMask, ISO 14229-1
New
High
The DCM and DEM shall provide the diagnostic status information according
to the DTCStatusMask, ISO 14229-1, Annex D5
Improved fault and event tracking and analysis
--ISO14229-1
4.1.2.9 [BSW04068] Standardized Event forget/unlearn counting

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.2.10
WP4.2.2.1.4
03.8.2004
Standardization of a event unlearn/forget behavior
New
High
The property of unlearning capability for diagnostic events shall be
configurable/calibratable. The number of cycles for event unlearning shall be
configurable/calibratable. The cycle definition itself is event specific property.
For emission related events based on the OBD/ISO defined cycles.
Improved fault and event tracking and analysis
--ISO14229-1
[BSW04069] DEM System status indication
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
DEM shall provide information on indicator upon request of SW-C or other
SW Basic modules.
New
High
DEM shall provide information on indicator (Lamps, text message, beep, ...)
upon request of SW-C or other SW Basic modules, which are configured
(registered) to this event.
Information distribution to the SW components
Indications of the Malfunction Indicator Lamp (MIL)
----
14 of 29
V2.1.1
R3.1 Rev 0001
4.1.2.11
[BSW04070] Event occurrence order definition
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.2.12
[BSW04071] Event importance definition
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.2.13
WP4.2.2.1.4
03.8.2004
DEM shall process the order of the event occurrences in an appropriate and
obvious manner.
New
High
- The occurrence order shall be recognizable by e.g. time stamps or
age. (storage of events shall be connected to age or timestamp)
- Reoccurrence of events takes over the old position of the event
- Reoccurrence of healed events are handled as new events.
Improved clustering and judging of events
--ISO14229-1
WP4.2.2.1.4
03.8.2004
The DEM shall process events according to their defined importance like
priority and/or severity.
New
High
The events shall be sorted or assigned to a specific priority (e.g. Severity
Mask ISO14229-1,Annex D3) representing their importance like:
- Healed events can be overwritten
- Privileged storing in case of Event Buffer filled up with less privileged
events
ISO14229-1
Improved clustering and judging of events
--ISO14229-1
[BSW04072] Extended event information
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
WP4.2.2.1.4
03.8.2004
The DEM shall provide additional event information to report the occurrence
of an event by km-stamp, driving cycles or time.
New
High
Fault duration e.g. by km-stamp, driving cycles or time
- Between failed and passed
- Since failed
- Since last clear
Improved clustering and judging of events/faults
-Document ID 004: AUTOSAR_SRS_Diagnosic
15 of 29
V2.1.1
R3.1 Rev 0001
Conflicts:
4.1.2.14
-ISO14229-1
[BSW04073] Event combination and compression
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
WP4.2.2.1.4
03.8.2004
DEM shall process combined events which may consist of several different
events.
New
High
The DEM shall allow for combining several individual events to a different
representing (combined) event that has its own event ID.
The configuration of the DEM shall allow for enabling and disabling the
support for combined diagnostic events.
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.2.15
[BSW04074] Event related environmental data
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.2.16
If combined diagnostic events are supported the configuration of the DEM

shall allow for assigning each diagnostic event the attribute combined
diagnostic event ID.
Improved clustering and judging of events/faults. Several internal hardware
faults of an electronic control unit can be mapped onto a single ECU
internal failure to reduce the number of Diagnostic Trouble Codes shown to
the technician in the service workshop.
----
WP4.2.2.1.4
03.8.2004
The DEM shall process event related environmental data.
New
High
It shall be possible to store different environmental data/freeze frame sets
per event.
Configuration/calibration:
The number of freeze frame sets shall be configurable due to the different
domain requirements and ECU complexities.
---
[BSW04075] Event and DTC assignment
Initiator:
Date:
Short Description:
WP4.2.2.1.4
03.8.2004
The DEM shall assign the SW component specific event to a customer
16 of 29
V2.1.1
R3.1 Rev 0001
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.2.17
specific DTC.
New
High
Assignment of events to customer specific / standardized DTCs which shall
be configurable related to number of DTCs.
----
[BSW04076] System Cycle definition
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
DEM shall provide a set of system cycles that may qualify the event in an
additional manner (e.g. OBD)
New
High
The cycles are used for event qualification or healing.
Typical cycles are
- driving cycle
- engine warm up cycle
- ignition on off cycle
- power up power down cycle
- operation active passive cycle
- in or out of voltage range cycle
Event status management, ISO14229
----
4.1.2.18 Interface and API

4.1.2.18.1
[BSW04077] Interface between DEM and NVRAM function
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The DEM uses standard mechanisms provided by NVRAM-Manager.
New
High
-Non volatile data storage
The DEM triggers data storage during normal ECU operation to avoid loss of
volatile data / event information.
NVRAM Manager
---
17 of 29
V2.1.1
R3.1 Rev 0001
4.1.2.18.2 [BSW04030] Interface between DEM and Monitoring SW
Component
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The DEM shall provide an interface via the RTE to monitoring SW
components for reporting and processing diagnostic test results.
New
High
The DEM shall provide via the RTE an Interface to Monitoring SW
Components for reporting and processing diagnostic results.
Monitoring SW-components report diagnostic results as soon as new results
are available.
Interface to event generating monitoring SW-Components
Ensure the basic diagnostic functionality
----
4.1.2.18.3 [BSW04031] Interface between DEM and Function Inhibition

Manager
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The DEM shall notify the Function Inhibition Manager (FIM) upon changes of
the event status in order to process them according to the SW components
dependencies.
New
High
Control (enable/disable) of functionalities of SW components based on the
following inhibit condition:
- faults
DEM information for Inhibition of functions.
Usage of DEM information for Inhibition of functions.
FIM is not specified yet.
---
18 of 29
V2.1.1
R3.1 Rev 0001
4.1.3 Diagnostic communication management (DCM)
4.1.3.1 [BSW04007] Provide Diagnostic service handling
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The DCM shall provide the Diagnostic service handling for the SWComponents which are using the DCM.
New
High
The DCM shall provide the diagnostic service handling, according to
ISO14229-1, ISO 15031-5 and ISO 15765-4 for the communication between
an AUTOSAR conform ECU and an internal tester or an external diagnostic
tool.
Only one diagnostic service instance in an ECU.
Communication with an external diagnostic tools in
- development
- manufacturing
- service (garage)
- OBD scan tools
Communication with an internal tester.
--ISO14229-1, ISO 15031-5, ISO 15765-4
4.1.3.2 [BSW04021] Switch diagnostic communication access

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
11.08.2004
The DCM shall support the handling of different diagnostic sessions in
parallel.
New
High
DCM needs to handle an established diagnostic communication and a
parallel diagnostic access request in parallel. This is necessary to open a
diagnostic access with 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
diagnostic communication as UDS.
A internal vehicle diagnostic tester communication is interrupted by OBD
diagnostic access request.
[BSW04032] Support of different diagnostic addresses
[BSW04061] Multiple or parallel usage from different applications of the DEM
functionality
---
19 of 29
V2.1.1
R3.1 Rev 0001
4.1.3.3
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.3.4
WP4.2.2.1.4
18.08.2004
Different diagnostic addresses shall be supported by multiple (physical)
channels.
New
High
Modern ECUs contain more than one functionality (e.g. board computer,
instrument cluster). Each functionality shall be addressable by a diagnostic
tool with a different diagnostic address. This does not imply that those
multiple request are allowed in parallel.
High flexibility and granularity for addressing of SW-Components
At the service (garage) a fault symptom is based on functionality. The
service only wants to address this functionality.
[BSW04021] Switch diagnostic communication access
[BSW04080] Support multi-channel capability for diagnostic communication
---
[BSW04080] Support multi-channel capability for diagnostic

communication
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
10.11.2004
The DCM shall support a multi-channel functionality for a parallel diagnostic
communication.
New
High
Advanced ECUs contain more than one functionality (e.g. board computer,
instrument cluster). The DCM shall ensure that external/internal diagnostic
tools could communicate to these functionalities in parallel. The DCM shall
provide a multi-channel capability to handle the communication in parallel.
External and internal diagnostic tools could access different functionalities
within the ECU in parallel.
Production: Parallel test sequence processing of different functions with an
external diagnostic tool.
Service (Garage): Reading the DTCs of all functions within an ECU in
parallel.
[BSW04021] Switch diagnostic communication access
---
20 of 29
V2.1.1
R3.1 Rev 0001
4.1.3.5
Supported diagnostic Services
4.1.3.5.1 [BSW04000] Support Diagnostic Standard UDS (ISO14229-1)

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
20.7.2004
The DEM and DCM shall support Diagnostic Standard UDS (ISO14229-1).
New
High
The DEM and DCM shall support all services of UDS Standard (ISO14229-1).
It will be the newest and harmonized Standard
Diagnostic with a UDS Tester
[BSW04004] Configuration of Services by ISO Standards
-ISO14229-1
4.1.3.5.2 [BSW04001] Support Diagnostic Standard OBD (ISO15031-5)

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
20.7.2004
The DEM and DCM shall support Diagnostic Standard OBD (ISO15031-5).
New
High
The DEM and DCM shall support all services of OBD Standard (ISO15031-5).
This standard is required for emission related control units by law
Diagnostic with a OBD Tester (e.g. Scan Tool)
[BSW04004] Configuration of Services by ISO Standards
-ISO15031-5
4.1.3.5.3 [BSW04005] SecurityAccess level handling is managed by DCM

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The DCM shall manage Security Access level handling.
New
High
The DCM shall manage the handling of the UDS-service SecurityAccess
(0x27) and also the Security level handling. The accessibility of the services
(service identifier) in the actual security level shall be checked by the DCM
Some diagnostic services are in dependence to a security access level.
Therefore it is necessary that the DCM has knowledge about the current
level and no service which is restricted by security will be processed without
authorization.
Not all diagnostic services are allowed in each security level.
[BSW04000] Support Diagnostic Standard UDS
---
21 of 29
V2.1.1
R3.1 Rev 0001
4.1.3.5.4 [BSW04006] Session handling is managed by DCM
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
Session handling of different diagnostic sessions is managed by DCM.
New
High
The DCM shall support the transition from a default session 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 that the DCM has knowledge about the current session and
no service 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.
Reduction of communication traffic on the network in order to get more
performance for the flash programming.
[BSW04005] SecurityAccess level handling is managed by DCM
---
4.1.3.5.5 [BSW04016] Provision of Busy Handling

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
11.08.2004
The DCM shall support a Busy handling by sending a negative response
0x78.
New
High
DCM shall provide the sending of the negative response 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 conditions.
When an application cannot provide the response in the protocol specific
time.
-ISO15765-3, ISO14229-1
4.1.3.5.6 [BSW04019] Application callback after transmit confirmation

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
WP4.2.2.1.4
11.08.2004
The DCM shall confirm transmitting if complete to continue processing.
New
High
In some cases it is necessary that the application starts execution of the
requested functionality after the positive response is completely transmitted.
The application needs the callback functionality to get the information that
the positive response is complete transmitted. After this callback the
application can execute the requested functionality.
This behavior is specified by ISO 14229.
22 of 29
V2.1.1
R3.1 Rev 0001
Use Case:
Dependencies:
Conflicts:
E.g. call of the reset function. This call needs to be done after transmission
of the positive response is over.
--ISO14229-1
4.1.3.5.7 [BSW04020] Suppression of Responses

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
11.08.2004
DCM shall suppress responses to diagnostic tool requests.
New
High
DCM shall suppress responses in following cases:
- Suppress positive response (SuppressPosRequest Bit set)
- Suppress negative responses (NRC 11, 12 and 31 at functional
addressing)
This behavior is specified by ISO 14229-1. Prevent bus burst as result of a
functional request.
-[BSW04000] Support Diagnostic Standard UDS
-ISO14229-1 chapter 6.5.2.2 Functionally addressed client request message
ISO15031-5 chapter 4.1.4 Data not available
4.1.3.5.8 [BSW04033] Upload/Download services for data handling

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
18.08.2004
The DCM shall support the upload/download services for reading/writing
data in an ECU in a extended and manufacturer specific diagnostic session.
New
High
The UDS services RequestDownload, RequestUpload, TransferData,
RequestTransferExit (0x34-0x37) are used for data handling, e.g. accessing
NVRAM. This does not interfere the reprogramming, because this is handled
by the bootloader.
Enable a possibility to modify set of parameters.
End of line configuration in the manufacturing.
-ISO14229-1
4.1.3.5.9 [BSW04036] Format checking of diagnostic services

Initiator:
Date:
Short Description:
Type:
Importance:
WP4.2.2.1.4
18.08.2004
The DCM shall check the format of diagnostic service. An incorrect service
shall be rejected by a negative response.
New
Low
23 of 29
V2.1.1
R3.1 Rev 0001
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.3.6
The format checking shall include the service identifier (SID). Existing subservice identifier shall be checked.
The checks shall include:
- diagnostic mode
- access-level
- message length
Note: Further checking is done by the application.
The application wont get a request with incorrect format.
Failure Handling in communication.
-ISO14229-1
Timing Requirements
4.1.3.6.1 [BSW04015] Provision of timing handling according to ISO15765-3

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
4.1.3.7
WP4.2.2.1.4
11.08.2004
The DCM shall support timing handling according to ISO15765-3.
New
High
In ISO15765-3 timing handling for physical and functional communication is
described. Also how to react on errors. DCM shall work according this
specification.
Timing parameters shall be configurable (see dependencies).
Ensure a steady and save communication link and guarantee specified
timing conditions.
Optimizing of timing for high performance during reprogramming.
[BSW04059] Configuration of timing parameter
-ISO15765-3
Resource Usage
4.1.3.7.1 [BSW04017] Provide optimized buffer handling

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
WP4.2.2.1.4
11.08.2004
The DCM shall provide an optimized buffer handling, which could be used by
the SW Component.
New
High
If an SW Component gets a diagnostic request, it could be possible that the
corresponding response required a huge amount of data to be transferred. In
the case that the SW Component is not able to handle the Data of the
response at one time, the DCM shall provide an optimized buffer handling to
realize the response.
If there is no mechanism, as e.g. a ring buffer or buffer swapping, each ECU
is forced to provide a Buffer, which could be as big as the maximum amount
of Data that could be transferred over the used physical connection at one
time.
Handling Diagnostic services, with the requirement to read a huge amount of
data out of the ECU. Typically, these are services, which are used to read all
24 of 29
V2.1.1
R3.1 Rev 0001
Dependencies:
Conflicts:
4.1.3.8
DTCs, transfer data, read or write data.

----
Interface and API
4.1.3.8.1 [BSW04078] Interface to fault memory, fault status

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
29.02.2004
The DCM shall use a common API of the diagnostic event manager to
access the fault memory.
New
High
An external or internal diagnostic tool needs access to the fault memory to
get or change information about the fault status. An interface between
diagnostic communication management and diagnostic event management
is required.
The DCM and the DEM are separated modules with the necessity to interact.
Therefore an interface is necessary.
A diagnostic test tool needs to read or clear the fault memory with the
corresponding diagnostic services, e.g. ReadDTCInformation,
ClearDiagnosticInformation
[BSW04002] Diagnostic event (error) management
---
4.1.3.8.2 [BSW04011] Provide diagnostic state information

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The DCM shall provide diagnostic state information (e.g. session state,
security access information) for AUTOSAR Software Component via RTE.
New
High
The Software modules above the RTE need to know about the actual
session and security state, because it is not predictable if the informations
lead to a different functional diagnostic behavior.
Functional requirement
With the diagnostic session which the garage is using, it is allowed to switch
between different sets of parameters.
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.
----
4.1.3.8.3 [BSW04003] Interface to PDU Router shall be network independent

25 of 29
V2.1.1
R3.1 Rev 0001
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
21.7.2004
The interface of the DCM to PDU Router (CAN/LIN; FlexRay; MOST) shall
be network independent.
New
High
All network (CAN, LIN, FlexRay, MOST) dependent parts shall be done
outside the DCM module. That means the module PDU Router shall provide
a network independent interface.
The DCM describes only the services for communication and the behavior of
network is out of scope. Highest granularity and best option to adapt
upcoming networks.
DCM has to be network independent. So, the interface to the Transport
Protocol shall be network independent.
----
4.1.3.8.4 [BSW04079] The size of a FreezeFrame shall be reported to the DCM

by the DEM
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
3.11.2004
The DEM shall be able to report the size of a FreezeFrame to the DCM.
New
High
If FreezeFrames are supported the DEM shall be able to determine the size
of a FreezeFrame and to provide this information via API call. The DCM
requires this information due to the allocation of memory space for the
storage of the FreezeFrame information.
FreezeFrames information to be provided for event analysis
An external testing tool connected to the vehicle requests currently stored
error codes and the corresponding environmental data.
----
4.1.4 Configuration
4.1.4.1 [BSW04059] Configuration of timing parameter
Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
WP4.2.2.1.4
30.08.2004
The DCM and DEM shall support the configuration of timing parameters.
New
High
Every physical layer requires specific timing parameter values therefore it is
necessary to include the ability to configure the timing constrains depending
on the used network. The timing parameters are set to default values when a
communication starts and shall be changeable at runtime.
Usability with different networks.
The diagnostic communication can be done at different networks (e.g.
CAN/LIN/FlexRay)
26 of 29
V2.1.1
R3.1 Rev 0001
Dependencies:
Conflicts:
[BSW04015] Provision of timing handling according to ISO15765-3

---
4.1.4.2 [BSW04024] Configurable size of transferred data

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
18.08.2004
The DEM and DCM shall handle a configurable size of data transferred
between DEM <-> DCM and DEM<->SW-C.
New
High
Configurable parameters for setting the maximum size of data to be
transferred via API-call.
Optimized usage of resources.
Transfer environmental / FreezeFrame data between DEM and DCM
----
4.1.4.3 [BSW04064] Event buffer shall be configurable concerning size

Initiator:
Date:
Short Description:
Type:
Importance:
Description:
Rationale:
Use Case:
Dependencies:
Conflicts:
WP4.2.2.1.4
03.8.2004
The DEM shall support buffers of scalable sizes for the storage of the
events, status information and environmental data.
New
High
a) For the internal administration the DEM needs an Event buffer which
shall be configurable depending on the number of the possible
events in the system i.e. related to all SW components which are
assigned to the DEM
b) The fault storage [event buffer] shall provide enough space to store
all high priority failures.
Processor resource constraints
In case of large Systems with many events a selection of Events shall take
place to fulfill NVRAM / RAM constraints of smaller processors.
[BSW106] (see SWS DEM document)
---
27 of 29
V2.1.1
R3.1 Rev 0001
4.2 Non-Functional Requirements (Qualities)

4.3 Output for other Modules
4.3.1 Requirements on Services (Services Layer)
[BSW04031] Interface to Function Inhibition Manager
[BSW04077] Interface between DEM and NVRAM function
[BSW04003] Interface to PDU Router shall be network independent
4.3.2 Requirements on RTE

[BSW04030] Interface between DEM and Monitoring SW Component
[BSW168] Diagnostic Interface of SW components
[BSW04011] Provide diagnostic state information
[BSW04012] Describe Interaction between Diagnostic service handling and Mode
management (e.g. ECU Reset)
4.3.3 Requirements on ECU Abstraction Layer

[BSW04077] Event management needs access to NVRAM function
[BSW04014] Diagnostic needs access to RAM, ROM, EEPROM (read Memory by
Address)
[BSW04003] Interface to PDU Router shall be network independent
28 of 29
V2.1.1
R3.1 Rev 0001
5 References
5.1 Deliverables of AUTOSAR
[1] General Requirements of Basic Software Modules
AUTOSAR_SRS_General.pdf
[2] Specification of the Virtual Functional Bus
AUTOSAR_VirtualFunctionBus.pdf
5.2 Related standards and norms

5.2.1 ITEA-EAST
[3] D1.5-General Architecture; ITEA/EAST-EEA, Version 1.0; chapter 3, page 72 et
seq.
[4] D2.1-Embedded Basic Software Structure Requirements; ITEA/EAST-EEA,
Version 1.0 or higher
[5] D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.
5.2.2 ISO
[6] ISO14229-1 Unified diagnostic services (UDS) - Part 1: Specification and
Requirements (ISO DIS 26.05.2004)
[7] ISO15031-5 Communication between vehicle and external equipment for
emissions-related diagnostics - Part 5: Emissions-related diagnostic services
(2005-01-13)
[8] ISO15765-3 Diagnostics on controller area network (CAN) - Part 3:
Implementation of unified diagnostic services (UDS on CAN) (2004-10-06)
[9] ISO 15765-4 Diagnostics on controller area network (CAN) - Part 4:
Requirements for emissions-related systems (2005 01-04)
29 of 29

Autosar Srs Diagnostic

Uploaded by

Copyright:

Available Formats

Autosar Srs Diagnostic

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autosar Srs Diagnostic

Uploaded by

Copyright:

Available Formats

Requirements on Diagnostic

Document Change History

Document ID 004: AUTOSAR_SRS_Diagnosic

Page left intentionally blank

Document ID 004: AUTOSAR_SRS_Diagnosic

Advice to users of AUTOSAR Specification Documents:

Document ID 004: AUTOSAR_SRS_Diagnosic

Scope of this document ....................................................................................... 6

How to read this document.................................................................................. 7

Acronyms and abbreviations ............................................................................... 9

Document ID 004: AUTOSAR_SRS_Diagnosic

1 Scope of this document

Document ID 004: AUTOSAR_SRS_Diagnosic

2 How to read this document

2.1 Conventions used

Document ID 004: AUTOSAR_SRS_Diagnosic

2.2 Requirements structure

Document ID 004: AUTOSAR_SRS_Diagnosic

3 Acronyms and abbreviations

External diagnostic tool

It is a device which is NOT permanently connected within the vehicle

Internal diagnostic tool

The external diagnostic tool is to be connected by a mechanic to

The meaning of internal diagnostic tool is NOT that it is included in

Document ID 004: AUTOSAR_SRS_Diagnosic

4.1.1.2 [BSW04082] Support of ISO15031-5 and SAE J1979

Document ID 004: AUTOSAR_SRS_Diagnosic

4.1.2.2 [BSW04057] Classification of event

Document ID 004: AUTOSAR_SRS_Diagnosic

4.1.2.4 [BSW04063] Single Event ID for each monitoring path

4.1.2.5 [BSW04065] Clearing of events or event groups

4.1.2.6 [BSW04066] Provision of a Secondary Event Memory

4.1.2.7 [BSW04058] Support deletion and reading services for Secondary

Document ID 004: AUTOSAR_SRS_Diagnosic

4.1.2.9 [BSW04068] Standardized Event forget/unlearn counting

[BSW04069] DEM System status indication

Document ID 004: AUTOSAR_SRS_Diagnosic

[BSW04070] Event occurrence order definition

[BSW04071] Event importance definition

[BSW04072] Extended event information

[BSW04073] Event combination and compression

[BSW04074] Event related environmental data

If combined diagnostic events are supported the configuration of the DEM

[BSW04075] Event and DTC assignment

[BSW04076] System Cycle definition

4.1.2.18 Interface and API

[BSW04077] Interface between DEM and NVRAM function

Document ID 004: AUTOSAR_SRS_Diagnosic

4.1.2.18.3 [BSW04031] Interface between DEM and Function Inhibition

Document ID 004: AUTOSAR_SRS_Diagnosic

4.1.3.2 [BSW04021] Switch diagnostic communication access

Document ID 004: AUTOSAR_SRS_Diagnosic

[BSW04032] Support of different diagnostic addresses

[BSW04080] Support multi-channel capability for diagnostic

Document ID 004: AUTOSAR_SRS_Diagnosic

Supported diagnostic Services

4.1.3.5.1 [BSW04000] Support Diagnostic Standard UDS (ISO14229-1)

4.1.3.5.2 [BSW04001] Support Diagnostic Standard OBD (ISO15031-5)

4.1.3.5.3 [BSW04005] SecurityAccess level handling is managed by DCM

Document ID 004: AUTOSAR_SRS_Diagnosic