Specification of Diagnostic Event Manager, AUTOSAR R22-11, CP, No.19
AUTOSARは、ISO、IEC、ITUと情報交換契約を結んでいません。
AUTOSAR文書には、ISO、IEC,ITU記述を全文引用することはできません。
WTO/TBT協定に基づき、国際的な調達は国際規格との差異を記述することにより文化依存しない仕様を目指します。
ISO、IEC、ITU文書を合わせて読むと技術内容は理解できます。
CAN、OSEK/VDX OS、DIAGは、ISO定義を先に確認しましょう。
OSEK COM、OSEK NMなどはISOの規定から基本的な部分で定義を変えています。
変更している部分を仕様等で明記するか、ISOを改定するとよいでしょう。
AUTOSARの参考文献欄の改定が進んでいません。
Glossary用語定義の網羅性が低いです。
本文を読む前に確認するとよいかもしれません。
本文を読んでから確認してもよいかもしれません。
AUTOSARが、2022年の版、R22-11公開しました。公開行事の模様は
AUTOSAR R22-11 Release Event 20221208
下記URL順次確認中です。
間違っていたら、いいね を押していただいて、コメント欄にご報告くださると幸いです。
編集リクエストが、構造的な変更をしている最中に、構造的な編集リクエストをしていただくと、
何をどう直したらいいかわからなくなってしまいます。自動修復ツールがつくれていません。ごめんなさい。
文書は検索してダウンロードすることができます。
クラウドサービスにありがちな、あるのにないかのような検索結果が出ることがあります。
要求/仕様（Requirement and Specification)
一覧
AUTOSAR R22-11 Adaptive Platform 一覧はこちら。
Adaptive Platform Release Overview, No.782, AP, AUTOSAR 22-11 新
Foundation Release Overview, No.781, FO, AUTOSAR 22-11 新
Classic Platform Release Overview, AUTOSAR R22-11, CP, No.0(2)
AUTOSAR R22-11 マラソン
AUTOSAR 文書番号と発行年
AUTOSAR R22-11で リンク切れ、表示しない文書
Qiitaの記事の一覧は作成中です。
AUTOSAR R22-11 Qiita記事一覧 新
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への道（詳細編）
2023年1月 記事数一覧
年末100記事を30点に仕上げる。
2023 書き初め
「はじめてのCAN/CANFD 」 ベクタージャパン ＜エンジニア夏休み企画>【読書感想文】
三方良し Udemy 車載LAN入門講座 CAN通信編
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者 ＜エンジニア夏休み企画 読書感想文＞
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 ＜エンジニア夏休み企画>【読書感想文】
詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために
AUTOSAR Abstract Platform User Group Weekly Report(1) 2022.1.8
AUTOSAR Abstract Platform User Group Weekly Report(2) 2022.1.15
overlapped definition in AUTOSAR short name. over 50.:英語(49)
短縮名。用語の衝突(用語・用例募集中)。英語(3) 仮説(88)
https://qiita.com/kaizen_nagoya/items/6a8eb7ffaa45eeb16624
ease press the like icon 💚 and follow me for your happy life.
202304 URL更新
Specification of Diagnostic Event Manager, AUTOSAR 19, R22-11, CP, 20230421
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20230212
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.