Specification of Diagnostic Event Manager, No.19, AUTOSAR R21-11(281) CP

Specification of Diagnostic Event Manager, No.19, 2021-11

https://www.autosar.org/fileadmin/standards/classic/21-11/AUTOSAR_SWS_DiagnosticEventManager.pdf

AUTOSAR R21-11記事一覧はこちら。

AUTOSAR 21-11,200文書読んだ。2022年5月に全部到達。

https://qiita.com/kaizen_nagoya/items/4043e8414f850ce266a4

AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成

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

# 用語(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
[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