Specification of Diagnostics, AUTOSAR 723, R23-11 AP

AUTOSARが2023年版、R23-11を公開しました。
https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_SWS_Diagnostics.pdf

R22-11
https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSAR_SWS_Diagnostics.pdf

R21-11
https://www.autosar.org/fileadmin/standards/R21-11/AP/AUTOSAR_SWS_Diagnostics.pdf

R20-11
https://www.autosar.org/fileadmin/standards/R20-11/AP/AUTOSAR_SWS_Diagnostics.pdf

R19-11
https://www.autosar.org/fileadmin/standards/R19-11/AP/AUTOSAR_SWS_Diagnostics.pdf

文書は検索してダウンロードできます。
https://www.autosar.org/




<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words in order.

# Release Overviews
AUTOSARには現在3つの分類があります。Foundation, CAN OSEK/VDXのClassic Platform, Ethernet/TCP/IP POSIXのAdaptive Platform.

Foundation Release Overview, AUTOSAR 781, R23-11, FO
https://qiita.com/kaizen_nagoya/items/f249bdb8c313d8bff883

Classic Platform Release Overview, AUTOSAR No.0 ,R23-11, CP
https://qiita.com/kaizen_nagoya/items/9d22c8722cbc0f42b137

Adaptive Platform Release Overview, AUTOSAR 782, R23-11, AP
https://qiita.com/kaizen_nagoya/items/13a104606a34fe24fcf7

# Qiita 記事一覧
Autosar Foundation R23-11 一覧
https://qiita.com/kaizen_nagoya/items/c30674cb2dac2fcbbd04

AUTOSAR Adaptive Platform R23-11一覧
https://qiita.com/kaizen_nagoya/items/1dece8799a730367b0dc

Autosar Classic Platform R23-11 一覧
https://qiita.com/kaizen_nagoya/items/f770f6c2906e1dcbf180


＃ 文書変更(Document Change) 
>• Document quality improvement and fixing bugs
• Incorporated Quality Scope Review Findings
• SOVD Concept Part 2 implemented
• Service 0x29 refinements
# 用語(term)

|Term|Description|
|:--|:--|
|AA |AUTOSAR Adaptive Application
|AP |AUTOSAR Adaptive Platform
|Channel |An abstraction of a network specific communication channel. In CAN networks a Channel can be identified via CAN identifier. In Ethernet networks a Channel might be defined by the quadruple Src-IP, Src-Port, Target-IP, Target-Port.
|CP| AUTOSAR Classic Platform
|DEXT| AUTOSAR Diagnostic Extract[3], describing diagnostic configuration of an ECU
|DM |AUTOSAR Adaptive Diagnostic Management
|DTC| Diagnostic Trouble Code according to ISO 14229-1[1]
|DDID |Dynamically Defined Data Identifier according to ISO 14229-1[1].
|DID| Data Identifier according to ISO 14229-1[1]. This 16 bit value uniquely defines one ore more data elements (parameters) that can are used in diagnostics to read, write or control data.
|ECU| Electronic control unit
|EDR| Extended Data Record
|Execution Management| Functional cluster Execution Management
|FDC |Fault Detection Counter according to 14229-1[1]. Has always the value range from -128 = FDCmin = "FinallyHealed" to +127 = FDCmax = "FinallyDefective"
|GID| Group identifier as used in DoIP
|MetaInfo| Meta-Information in the form of a key-value map, which is given from DM to external service processors.
|NRC |Negative Response Code used by UDS in the diagnostic response to indicate the tester that a certain failure has occurred and the diagnostic request was not processed.
|OBD| "On-Board Diagnostics"; Generally: A vehicles ability for self diagnosis and reporting to external test tools. Specifically here, the protocol is meant, as defined in SAE J1979, ISO 15031, ISO 27145 and others.
|OEM |"Original Equipment Manufacturer", but in this document herein, it is used for "Vehicle Manufacturer".
|PDID |Periodic Data Identifier according to ISO 14229-1[2].
|PowerMode| Vehicle basic status information retrieval of DoIP
|SA| SourceAddress of a UDS request
|SID |Service Identifier, identifying a diagnostic service according to UDS, such as 0x14 ClearDiagnosticInformation
|TA| TargetAddress of a UDS request
|UDS| Unified Diagnostic Services
|VIN |Vehicle Identification Number according to ISO-3779
|Dcm| Diagnostic Communication Manager (Module of the AUTOSAR Classic Platform)
|DoIP| Diagnostics over Internet Protocol (Communication protocol of automotive electronics according to ISO-13400[5])
|Aging| Unlearning/deleting of a no longer failed event/DTC after a defined number of operation cycles from event memory.
|Diagnostic Client| A Diagnostic Client is a diagnostic service requester, i.e. sends a UDS request to the Diagnostic Server. Usually the Diagnostic Client is an external tester equipment but can also be another vehicle internal ECU.
|Diagnostic Communication Management|Diagnostic Communication Management is the part of the Diagnostic Management which belongs to tester communication and the processing of UDS services.
|Diagnostic Conversation| Diagnostic Conversation represents a conversation between Diagnostic Client (Tester) and Diagnostic Server.
|Diagnostic Event Management| Diagnostic Event Management is the part of the Diagnostic Management which belongs to processing and storing of diagnostic events and associated data.
|Diagnostic Management| Diagnostic Management is a placeholder for the complete functionality of diagnostic communication and event handling.
|Diagnostic Server instance| Diagnostic Server (DM) is intended to support an own Diagnostic Server instance per installed SoftwareCluster, see section 7.5 for a detailed description. Each of those Server instances has and manages its own resources and is responsible for dispatching and processing of diagnostic services.
|Diagnostic Service instance| A diagnostic service instance implements a concrete use of a diagnostic service in a given context. It refers to a DiagnosticServiceClass and the DiagnosticAccessPermission , see 7.5.1.5.3 for a detailed description.
|Displacement| In case of an Event memory overflow: Replacing the most insignificant stored event memory entry by a reported event which needs to be stored and is more significant.
|DTC group| Uniquely identifies a set of DTCs. A DTC group is mapped to the range of valid DTCs. By providing a group of DTCs it is expressed that a certain operation is requested on all DTCs of that group. The DTC group definition is provided by ISO 14229-1[1] and OEM/supplier-specific.
|DTCStatusAvailabilityMask| The DTCStatusAvailabilityMask - byte is used in UDS responses to requests for certain sub-functions of service 0x19. It express which of the UDS DTC status bits are supported by the DM for masking purposes.
|Enable Conditions| The criteria / conditions under which the test results from the monitors in the AA’s are valid and shall be processed by DM. Configuration is done per event.
|Extended Data Records| Contains statistical data for a DTC. Extended data records are assigned to DTCs and maintained and stored by the DM.
|Event |An event (also diagnostic event) uniquely identifies a fault path of the system. An application monitors the system and reports events to the DM.
|Event memory |The DM stores information about events in the event memory. There can be multiple event memories, each keeping information independently from each other. Examples of the event memory is the UDS primary event memory or the up to 256 user-defined event memories.
|Event memory overflow |An event memory overflow occurs, if this specific event memory is full and the next event occurs to be stored in this event memory.
|Event status| Bit-packed status information based on Event level. Contains the following bits: Nr. Definition: • 0 testFailed • 1 testFailedThisOperationCycle • 6 testNotCompletedThisOperationCycle Compare UDS DTC status bit
|Fail-safe reaction| (Sometimes also called "limp home mode"): Reaction to avoid or minimize harm or damage in case of a failure.
|GroupOfAllDTCs |Identifies a special DTC group that contains all DTCs. This DTC group is identified by the DTC value 0xFFFFFF in 14229-1[1] and contains by default all DTCs of a fault memory. It is present by default in the DM and requires no configuration.
|Internal, External| Classifies if a DiagnosticDataElement is either managed internally inside DM or by an external adaptive applications, see 7.5.4.1 for the precise definition.
|Internally, Externally| Definition of the support type of a SID by the DM. Internally means processing is done by DM itself, Externally means an external service processor is used.
|internal data element| A DiagnosticDataElement which is provided by the DM itself. See also 7.5.4.1.
|Monitor| A monitor (also diagnostic monitor) is a piece of software running within an application, monitoring the correct functionality of a certain system part. The result of such a function check is reported to the DM in form of a diagnostic event.
|Operation cycle| A new operation cycle is the start of a new monitoring cycle. This is reflected in a reset of the testFailedThisOperationCycle and testNotCompletedThisOperationCycle bits in the DTC status and optional notification to the monitor to restart the monitoring.
|Primary event memory| The primary event memory is used to store events and event related data. It is typically used by OEMs for after sales purposes, containing information to repair the vehicle.
|Snapshot Record |Set of measurement values stored in the fault memory at a certain point of time during fault detection. It is used to gain environmental data information for occurred faults.
|SoftwareCluster| A SoftwareCluster groups all AUTOSAR artifacts which are relevant to deploy software on a machine. This includes the definition of applications, i.e. their executables, application manifests, communication and diagnostics. In the context of diagnostics a SoftwareCluster can be addressed individually by its own set of diagnostic addresses.
|SourceAddress| A Source Address is used to encode client and server identifiers. In a UDS request the source address encodes the Diagnostic Client whereas the source address in a UDS response encodes the Diagnostic Server.
|TargetAddress |A Target Address is used to encode client and server identifiers. In a UDS request the target address encodes the Diagnostic Server whereas the target address in a UDS response encodes the Diagnostic Client.
|Transport Protocol Handler |A subcomponent of DM implementing a particular Transport Protocol (either DoIP or any other proprietary UDS Transport Layer).
|Transport Protocol Manager| Link between UDS Transport Layer and Application Layer.
|UDS service| A diagnostic service as defined in ISO 14229-1[1].
|UDS DTC status bit |UDS DTC status bit as defined in ISO 14229-1[1] Annex D.2; Each single bit position represents and documents a certain status information for the connected DTC. The following eight bits are defined: Nr: Definition: 0 testFailed 1 testFailedThisOperationCycle 2 pendingDTC 3 confirmedDTC 4 testNotCompletedSinceLastClear 5 testFailedSinceLastClear 6 testNotCompletedThisOperationCycle 7 warningIndicatorRequested All eight bits constitute the UDS DTC status byte. Compare Event status 
|UDS DTC status byte |Bit-packed DTC status information byte as defined in ISO 14229- 1[1], based on DTC level. Contains the UDS DTC status bits.
|User-defined event memory |The user-defined event/fault memory is used by the UDS service 0x19 with subfunctions 0x17, 0x18 and 0x19. It behaves as the primary event memory but contains data independent from the primary fault memory. It is used to store information that are relevant for different purposes such as warranty or development.
|Non-volatile Memory |In the context of DM, Non-volatile Memory refers to the persistent information over the shutdown of the DM process. This does not depend on HW details.

# References
1] Unified diagnostic services (UDS) – Part 1:Application layer (Release 2020-02) https://www.iso.org
[2] ASAM SOVD Service-Oriented Vehicle Diagnostics - API Specification V1.0.0 http://www.asam.net
[3] Diagnostic Extract Template AUTOSAR_CP_TPS_DiagnosticExtractTemplate
[4] Glossary AUTOSAR_FO_TR_Glossary
https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_TR_Glossary.pdf
[5] Road vehicles – Diagnostic communication over Internet Protocol (DoIP) – Part 2: Network and transport layer requirements and services (Release 2019-12) https://www.iso.org
[6] Specification of Adaptive Platform Core AUTOSAR_AP_SWS_Core
[7] Explanation of Adaptive Platform Software Architecture AUTOSAR_AP_EXP_SWArchitecture
[8] Requirements on Diagnostics AUTOSAR_FO_RS_Diagnostics
[9] Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2:Network layer services
[10] Specification of Manifest AUTOSAR_AP_TPS_ManifestSpecification
[11] Specification of Intrusion Detection System Manager for Adaptive Platform AUTOSAR_AP_SWS_IntrusionDetectionSystemManager
[12] Unified diagnostic services (UDS) - Part 2:Session layer services (Release 2021- 10)
https://www.iso.org
[13] Unified diagnostic services (UDS) – Part 1:Application layer (Release 2013-03) https://www.iso.org





## 補足資料（Additions）
祝休日・謹賀新年：2024年の目標
https://qiita.com/kaizen_nagoya/items/b659d922327a7dcdc898

2023 Countdown Calendar 主催・参加一覧
https://qiita.com/kaizen_nagoya/items/c4c2f08ac97f38d08543

CountDownCalendar月間　いいねをいただいた記事群　views　順
https://qiita.com/kaizen_nagoya/items/583c5cbc225dac23398a

Countdown Calendar 2023, 百記事目を書くにあたって。
https://qiita.com/kaizen_nagoya/items/45185a04cfd88b71256a

1年間をまとめた「振り返りページ」＠２０２３
https://qiita.com/kaizen_nagoya/items/bcd1ebd49d3a9e8c7a90

AUTOSAR 文書番号
https://qiita.com/kaizen_nagoya/items/8b894228a0b76c2265c7

AUTOSAR Countdown Calendar 2023
https://qiita.com/advent-calendar/2023/autosar

AUTOSAR Abstract Platformへの道 R22-11
https://qiita.com/kaizen_nagoya/items/8ac2826635a8c536c7ec

自動車　記事　１００
https://qiita.com/kaizen_nagoya/items/f7f0b9ab36569ad409c5

Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>
https://qiita.com/kaizen_nagoya/items/24a1ba5da3d09b2a95d1

JAXA/IPA クリティカルソフトウェアワークショップ WOCS言語関連発表(改定版)
https://qiita.com/kaizen_nagoya/items/4789832baf494cb74626

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong.


# 文書履歴(document history)
ver. 0.01 初稿 　20240102
### 最後までおよみいただきありがとうございました。
いいね　💚、フォローをお願いします。
#### Thank you very much for reading to the last sentence.
Please press the like icon 💚　and follow me for your happy life.