Specification of Diagnostic Event Manager, AUTOSAR 19, R22-11, CP, 20230421

AUTOSARは自動車用OSの業界団体規格です。　
業務で利用する場合には、会員になることを条件にしています。

2002年から20年経ち、当初の狙いの段階に近づいてきました。

MATLABでモデルさえ記述すれば、あとは自動生成だけでソフトが完成するところまで、あと一歩です。
Ethernet, UNIXが生まれて20年で大衆化したのと同じように考えると分かりやすいでしょう。　

AUTOSARの上で動く、クラウド対応のミドルウェアが出て、開発も運用もクラウドになれば、一気にAUTOSARは大衆化するでしょう。

AUTOSAR Abstract Platformへの道 R22-11

https://qiita.com/kaizen_nagoya/items/8ac2826635a8c536c7ec

# 2023年4月URL変更
この項は2023年4月21日、AUTOSARの文書のURLが変更になった。
/classic/22-11/
が
/R22-11/CP/
過去記事で、URLでエラーが出たら書き換えてみてください。

/adaptive/22-11/
は　
/R22-11/AP/

/foundation/22-11/
は　
/R22-11/FO/
です。
## 2023年11月URL変更
2023年11月にもAUTOSAR文書のURLが変更になっている。
/user_upload/standards/classic/21-11/
を
/standards/R21-11/CP/
などに書き換えてください。

/user_upload/standards/adaptive/21-11/
を
/standards/R21-11/AP/

/user_upload/standards/foundation/21-11/
を
/standards/R21-11/FO/

お手数をおかけします。
１年に２度URLを変更するなんて、新しい記事が書ける。とても嬉しい。

# 一覧

AUTOSAR R22-11 Qiita記事一覧 20230421 。

https://qiita.com/kaizen_nagoya/items/81a35774f1aa3d64d3f6

この記事の表題の最後に「20230421」を加えます。

<この項は書きかけです。順次追記します。>

AUTOSARが、2022年の版、R22-11を公開しました。

https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_DiagnosticEventManager.pdf

R21-11

https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SWS_DiagnosticEventManager.pdf

R20-11

https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_DiagnosticEventManager.pdf

R19-11

https://www.autosar.org/fileadmin/standards/R19-11/CP/AUTOSAR_SWS_DiagnosticEventManager.pdf

https://www.autosar.org/

文書は検索してダウンロードできます。

R20-11,R21-11, R22-11の３年分だけになりました。

公開行事の模様は

AUTOSAR R22-11 Release Event 20221208

https://qiita.com/kaizen_nagoya/items/18471d0b340480fdcd42

Classic Platform Release Overview, AUTOSAR No.0 ,R22-11, CP, 20230421

https://qiita.com/kaizen_nagoya/items/9d22c8722cbc0f42b137

Foundation Release Overview, AUTOSAR, 781, R22-11, FO, 20230421

https://qiita.com/kaizen_nagoya/items/596a7e2ec86913daa3c2

Adaptive Platform Release Overview, AUTOSAR 782, R22-11, AP, 20230421

https://qiita.com/kaizen_nagoya/items/fc8e02e8cb07411dbc2a

# 要求仕様対応(Requirement and Specification)
# Abstract Platformとの関係

RS統合, Diag統合

<この項は書きかけです。順次追記します。>

## 文書変更(Document Change) 

>• Add Interface Intrusion Detection System Manager
• Support J1979-02 use case
• Rename
DemDebounceTimeBaseClass to
DemDebounceTimeBasedClass
• Rename
DemDebounceTimeBaseRef to
DemDebounceTimeBasedClassRef
• Add API Dem_ResetMonitorStatus



# 用語(terms)
|Term|Description|
|:--|:--|
|Activation Mode 1 |Absence of malfunction - The MIL shall blink for one flash.
|Activation Mode 2|"on-demand-MI" - The MIL shall show blink for two flashes if the OBD system would command an on-demand-MI according to the discriminatory display strategy.
|Activation Mode 3|"short-MI" - The MIL shall blink for three flashes if the OBD system would command a short-MI according to the discriminatory display strategy.
|Activation Mode 4|"continuous-MI" - The MIL shall remain continuously ON ("continuous-MI") if the OBD system would command a continuous-MI according to the discriminatory display strategy.
|Aging |Unlearning/deleting of a no longer failed event/DTC after a defined number of operation cycles from event memory.
|Aging Counter|The "Aging Counter" or "Aging Cycle Counter" or "DTC Aging Counter" specifies the counter which is used to perform Aging. It counts the number of operation cycles until an event/DTC is removed from event memory.
|Class B1 counter| Number of engine hours during which a Class B1 malfunction has been Confirmed and TestFailed.
|Combined DTC|Normal DTC, but referenced by multiple events reported by several monitors (e.g. ECU Defect, consisting of different HW defects).
|Continuous-MI counter| Hours run by the engine while a continuous MI is commanded.
|Cumulative Continuous-MI counter|Number of engine hours during which MI has been continuously commanded to be on during its lifetime.
|Debounce counter| Internal counter for counter-based debouncing algorithm(s).
|DemComponent / Monitored Component|A monitored component is a part of the system, which is checked for proper operation by one or several monitorings. (see chapter 7.5)
|Dem-internal data value |Some data values (e.g. the occurrence counter) are calculated by the Dem module itself internally.
|Denominator| The denominator of a specific monitor m (Denominatorm) is a counter indicating the number of vehicle driving events, taking into account conditions specific to that specific monitor.
|Dependent / Secondary ECUs| Dependent / Secondary (or dep. / sec. ) ECUs are always related to a Master or a Primary ECU.
|Directed acyclic graph| Dependency graph without circular dependencies.
|Displacement|Replacing the the most insignificant event memory entry by a more significant event memory entry which needs to be stored.
|DTC group|Uniquely identifies an set of DTCs. A DTC group is mapped into 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[2] and OEM/supplier specific.
|DtcGroupAllDtcs| Grouping of all configured DTCS (representation is 0xFFFFFF).
|Event combination|Event combination is a method to merge several events to one specific combined DTC. It is used to adapt different monitor results to one significant fault, which is clearly evaluable in a service station.
|Event debouncing|Debouncing is a specific mechanism (e.g. counter-based) to evaluate, if the diagnostic event gets qualified. This works on top of potential signal debouncing and can be done within the SW-C or inside the Dem.
|Event confirmation|A diagnostic event is confirmed in case of repeated detection of qualified events over cycles or time evaluated by means of fault confirmation counters. Therefore, also the UDS status bit 3 (ConfirmedDTC) is set. Event memory An event memory (e.g. Primary memory) consists of several event memory entries.
|Event memory entry|The event memory entry is a single storage container for an event and its event related data. The event memory entry is dynamically assigned to specific events.
|Event memory overflow indication|The event memory overflow indication indicates, if this specific event memory is full and the next event occurs to be stored in this event memory.
|Event qualification|A diagnostic event is qualified in case of a passed or a failed result is set (Dem-internal or reported from another BSW module or SW-C).
|Event related data|Event related data is additional data, e.g. sensor values or time stamp/mileage, which is stored with an event in an event memory. ISO defines two types of event related data: freeze frames (snapshot records) and extended data.
|Event status byte| Status byte as defined in ISO 14229-1 [1], based on event level.
|Extended data record| An extended data record is a record to store specific information assigned to a fault.
|Failure counter| The Failure counter represents the Trip Counter according to ISO14229-1 [2]. The Trip Counter counts the number of operation cycles (driving cycles) where a malfunction occurred. If the counter reaches the threshold (e.g., 2 driving cycles) the confirmed bit changes from 0 to 1.
|Fault Detection Counter| sint8 value as used in ISO and FDC-APIs.
|Freeze frame| Freeze frame is defined as a record of data (DIDs/PIDs). Freeze frames are the same as SnapShotRecords in ISO-14229-1[2].
|General Denominator|The general denominator is a counter indicating the number of times a vehicle has been operated, taking into account general conditions.
|Healing|Switching off the warning indicator including the handling of reported passed results over a period of time / several operation cycles
|In-Use performance ratio |The in-use performance ratio (IUPR) of a specific monitor m of the OBD system is: IUPRm = Numeratorm / Denominatorm
|Master ECU|As a primary ECU a Master ECU stores “it’s own” and “reported errors” of related dep. / sec ECUs in it’s event memory. Beside this a Master has to fulfill special Master tasks as MIL Master or provision of “general nominator” information.
|Monitor|A diagnostic monitor is a routine entity determining the proper functionality of a component. Alternatively the term “diagnostic function” can be used.
|Numerator|The numerator of a specific monitor m (Numeratorm) is a counter indicating the number of times a vehicle has been operated such that all monitoring conditions necessary for that specific monitor to detect a malfunction have been encountered.
|NvM is marked for NvM_WriteAll| The Dem has called NvM_SetRamBlockStatus() to set the according NvM Block to be written by NvM_WriteAll()
|Operating cycle|An ‘operation cycle’ is the base of the event qualifying and also Dem scheduling (e.g. ignition key off-on cycles, driving cycles, etc.)
|OBD|On-Board Diagnostics, or OBD is a generic term referring to a vehicle’s self-diagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access to state of health information for various vehicle sub-systems.
|OBD ECUs|"In a vehicle there can be 3 different types of OBD ECUs: • Master ECU (one per vehicle) • Primary ECUprimary ECUs (several per vehicle) • Dependent / Secondary ECUs (several per vehicle)
|OBD UDS DTC separation|The feature will report a different 3 byte DTC number for SAE J1979-2 based UDS communication than for none J1979-2 UDS communication
|P-Code |Power train code
|PFC cycle |Permanent fault code - driving cycle (OBD Term)
|Positive Callback from NvM|The Dem module shall use the APIs NvM_WriteBlock and NvM_GetErrorStatus of the NVRAMManager [5], if there is the necessity to store data between Dem_Init and Dem_Shutdown. Furthermore the API NvM_GetErrorStatus shall wait for positive response if writing of block completed successfully.
|PossibleErrors| PossibleErrors means the ApplicationErrors as defined in meta model
|Primary ECU |A primary ECU stores “it’s own” and "reported errors" of related dep. / sec ECUs in it’s event memory
|RBM cycle |OBD Term: General Nominator / Rate-based monitoring - driving cycle (OBD Term)
|Readiness|The readiness refers to the tested bits TestNotCompletedSinceLastClear (bit 4) and TestNotCompleteThisOperationCycle (bit 6) of the UDS status byte.
|Triggered to NvM|The Dem module shall use the API NvM_WriteBlock of the NVRAMManager [5], if there is the necessity to trigger the storage of data between Dem_Init and Dem_Shutdown. Furthermore the Dem module shall wait for positive response of NvM_WriteBlock if request has been accepted.
|UDS status bit 0 |testFailed bit of the UDS status byte. Indicates the result of the most recently performed test.
|UDS status bit 1|testFailedThisOperationCycle bit of the UDS status byte. Indicates whether or not a diagnostic test has reported a testFailed result at any time during the current operation cycle.
|UDS status bit 2|pendingDTC bit of the UDS status byte. Indicates whether or not a diagnostic test has reported a testFailed result at any time during the current or last completed operation cycle.
|UDS status bit 3|confirmedDTC bit of the UDS status byte. Indicates whether a malfunction was detected enough times to warrant that the DTC is desired to be stored in long-term memory.
|UDS status bit 4|testNotCompletedSinceLastClear bit of the UDS status byte. Indicates whether a DTC test has ever run and completed since the last time a call was made to ClearDiagnosticInformation.
|UDS status bit 5|testFailedSinceLastClear bit of the UDS status byte. Indicates whether a DTC test has completed with a failed result since the last time a call was made to ClearDiagnosticInformation.
|UDS status bit 6|testNotCompletedThisOperationCycle bit of the UDS status byte. Indicates whether a DTC test has ever run and completed during the current operation cycle.
|UDS status bit 7|warningIndicatorRequested bit of the UDS status byte. Report the status of any warning indicators associated with a particular DTC.
|UDS status byte |Status byte as defined in ISO 14229-1 [1], based on DTC level.
|API |Application Programming Interface
|BSW| Basic Software
|CDD |Complex Device Driver
|CRC |Cyclic Redundancy Check
|Dcm| Diagnostic Communication Manager
|Dem| Diagnostic Event Manager
|Det| Default Error Tracer
|DID |Data Identifier
|DTC |Diagnostic Trouble Code
|DTR |Diagnostic Test Result
|DYC| OBD Term: Driving Cycle (OBD Term)
|ECU| Electronic Control Unit
|EcuM |Electronic Control Unit Manager
|FDC |Fault Detection Counter
|Fim |Function Inhibition Manager
|FMI |Failure Mode Indicator (SAE J1939)
|FT|B Failure Type Byte
|HW |Hardware
|ID |Identification/Identifier
|ISO| International Standardization Organization
|IUMPR |In Use Monitoring Performance Ratio (OBD Term)
|J1939Dcm| SAEJ1939 Diagnostic Communication Manager
|MIL| Malfunction Indicator Light (SAE J1979) or Lamp (SAE J1939)
|NVRAM| Non volatile RAM
|OBD| On-Board-Diagnostics
|OC| Occurrence Count (SAE J1939)
|OEM| Original Equipment Manufacturer (Automotive Manufacturer)
|OS| Operating System
|PID |Parameter Identification (SAE J1587 or SAE J1979)
|PTO |Power Take Off
|RAM |Random Access Memory
|ROM |Read-only Memory
|RTE |Runtime Environment
|SPN |Suspect Parameter Number (SAE J1939)
|SSCP |synchronous server call point
|SW| Software
|SW-C |Software Component
|UDS |Unified Diagnostic Services
|VOBD |Vehicle On-Board-Diagnostic
|WUC |OBD Term: Warm up cycle (OBD Term)
|WIR| Warning Indicator Request
|WWH-OBD| World Wide Harmonized On-Board-Diagnostic

## 英日
日本語は仮訳

T.B.D.

# 参考(reference)

[1] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Release 2006-12)
http://www.iso.org
[2] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Release 2013-03)
http://www.iso.org
[3] Road vehicles – Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements – Part 1: General information and use case definition
http://www.iso.org
[4] Glossary, AUTOSAR_TR_Glossary
https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_TR_Glossary.pdf
[5] Specification of NVRAM Manager
AUTOSAR_SWS_NVRAMManager
[6] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral
[7] Specification of a Diagnostic Communication Manager for SAE J1939
AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager
[8] Requirements on Function Inhibition Manager
AUTOSAR_SRS_FunctionInhibitionManager
[9] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager
[10] Requirements on Diagnostics
AUTOSAR_RS_Diagnostics
[11] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral
[12] Road vehicles – Communication between vehicle and external equipment for emission-related diagnostic – Part 5: Emission-related diagnostic services. http://www.iso.org
[13] SAE J2012-DA Digital
[14] SAE J1939-73 Application Layer – Diagnostics
[15] Road vehicles – Interchange of digital information on electrical connections between towing and towed vehicles – Part 4: Diagnostic communication http://www.iso.org
[16] ISO 17356-3: Road vehicles – Open interface for embedded automotive applications – Part 3: OSEK/VDX Operating System (OS)
[17] SAE J1979
[18] SAE J1979-DA Digital Annex of E/E Diagnostic Test Modes
[19] Title 13, California Code Regulations, Section 1971.1, On-Board Diagnostic System Requirements for 2013 and Subsequent Model-Year Heavy-Duty Engines (HD OBD)
[20] Title 13, California Code Regulations, Section 1968.2, Malfunction and Diagnostic System Requirements for 2004 and Subsequent Model-Year Passenger Cars,
Light-Duty Trucks, and Medium-Duty Vehicles and Engines (OBD II) (Biennial Review MY08-11)
http://www.arb.ca.gov/regact/obdii06/19682clean.pdf
[21] Road vehicles – Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements – Part 3: Common message dictionary http://www.iso.org
[22] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[23] Diagnostic Extract Template
AUTOSAR_TPS_DiagnosticExtractTemplate

# 関連文書(Related document)

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

CAN(controller area network) 

https://qiita.com/kaizen_nagoya/items/e8c0bd7bfb2827b83de9

「はじめてのCAN/CANFD 」 ベクタージャパン ＜エンジニア夏休み企画>【読書感想文】

https://qiita.com/kaizen_nagoya/items/1fee270be00ef90ca4ec


三方良し　Udemy 車載LAN入門講座 CAN通信編

https://qiita.com/kaizen_nagoya/items/bed038c52510fea72c0a


詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者　 ＜エンジニア夏休み企画 読書感想文＞

https://qiita.com/kaizen_nagoya/items/e9971698a108c3dba794

詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 ＜エンジニア夏休み企画>【読書感想文】

https://qiita.com/kaizen_nagoya/items/e156cbdd5fce9263776e

詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために

https://qiita.com/kaizen_nagoya/items/44a9e6b0f5363b4a5b35

 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞

# 文書履歴(document history)
ver. 0.01初稿　　20230701

### 最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

####  Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.