Summary:
DEM is an AUTOSAR basic software module with DTC as the core, which realizes the functions of monitoring, reporting and storage of DTC. If you need to further study AUTOSAR diagnosis, you also need to study DCM, Doip, Cantp and other modules systematically.
foreword
Dem is one of the modules with the most configuration items and the most complex functions in AUTOSAR. It is mainly responsible for recording fault diagnosis and its associated data. It is a crucial module to realize the diagnosis function. This article will talk about the functions of Dem in the simplest way. , talk thoroughly. For your convenience, the following is the outline of this article.
1. Basics of fault diagnosis
When a person suffers from a disease, he needs medical treatment. Doctors find out the cause of the disease based on various test results, and come up with a diagnosis and treatment strategy. When a car breaks down, the DTC fault code is equivalent to the "inspection result". Automotive engineers can obtain the fault information by looking up the table through the identification code, such as fault trigger conditions, fault removal conditions, system function performance, etc., to obtain Strategies to resolve the failure.
DTC (Diagnostic Trouble Code), as its name implies, is a diagnostic trouble code, which is used to record the identification code presented to everyone when the ECU occurs or detects a certain fault.
1.1 Composition of DTC
DTC fault code is a 4-byte identifier consisting of the following two parts: DTC Catogory and Failure Type, where DTC Catogory can further define its scope according to the four subsystems of Powertrain, Body, Chasis and Network, referred to as The four subsystems of the PBCU are shown in the following table:
1.2 Significance of DTC
The fault code has the following two meanings:
1) Off-line inspection of the production line: the development of a car's parts, system integration, and vehicle assembly, the process involved is long and the number of parts is large, which can be said to be quite complicated. In order for the vehicles produced on the production line to go off the assembly line normally and go on the road safely, it is necessary to ensure that there is no problem with the components themselves and the mutual cooperation of the components before the vehicle goes off the assembly line. Therefore, during the electric inspection process of the production line, the fault code of the whole vehicle will be read, and the fault code will be used to indicate whether the vehicle is normal.
2) Vehicle maintenance: When the vehicle breaks down, how can the maintenance engineer quickly locate the faulty parts? A vehicle is composed of tens of thousands of parts. If you rely on maintenance engineering to check slowly based on experience, the efficiency will be extremely low. Therefore, the maintenance engineer will use the diagnostic instrument to read the fault codes of the whole vehicle, compare the fault codes with the fault symptoms, and quickly come up with maintenance strategies.
1.3 DTC fault types
Taking the non-emission related ECU as an example, the DTC fault types can be divided into the following parts:
Hardware failure: failure of hardware itself such as RAM, Flash, CPU clock, etc. Software failure: such as configuration word failure, calibration failure or customer-defined software functional failure External environment failure: overvoltage or undervoltage, high ambient temperature or Communication-related failures such as too low : such as message loss, invalid signal, Checksum/Rolling failure, etc.
1.4 DTC Status Bit Introduction
Each DTC has a byte to indicate the status of the fault, and the meaning of each bit in this byte is as follows:
| status Of DTC: bit field name |
Bit | Bit state | Description |
| testFailed | 0 | 0 | DTC is not failed at the time of the request |
| testFailedThisOperationCycle | 1 | 0 | DTC failed during the current operation cycle |
| pendingDTC | 2 | 0 | DTC was not failed on the current or previousoperation cycle |
| confirmedDTC | 3 | 0 | DTC is not confirmed at the time of the request |
| testNotCompletedSinceLastClear | 4 | 0 | DTC test was completed since the last code clear |
| testFailedSinceLastClear | 5 | 0 | DTC test never failed since last code clear |
| testNotCompletedThisOperationCycle | 6 | 0 | DTC test completed this operation cycle |
| warningIndicatorRequested | 7 | 0 | Server is not requesting warningIndicator to beactive |
The specific explanation is as follows:
Bit0: The test result at the request time is a failure; Bit1: At least one failure has occurred in the current ignition cycle; Bit2: The test result is not a failure in the current or last ignition cycle; Bit3: The DTC is confirmed at the request time, and the general confirmation is in an ignition cycle An error occurs once in the cycle; Bit4: The test result has been completed since the last clearing of DTC, that is, the test result is PASS or FAIL; Bit5: The test result is not FAIL since the last clearing of DTC; Bit6: In the current ignition cycle The test result has been completed, that is, PASS or FAIL status; Bit7: ECU has not received the request to turn on the warning light
1.5 Freeze frame and extended data
It can be seen from the above that the 8 bits in the DTC can describe the DTC status, but the information that can be carried by the 8 bits is limited, and it can only indicate whether the fault is a current fault or a historical fault. How to record key information such as vehicle speed, temperature, fuel volume, and electricity when a fault occurs?
The UDS stipulates that the freeze frame can be used to record the details of the fault, and the extended data can provide extended information related to the fault code, including the aging counter.
| type | composition | content |
| freeze frame | Consists of a series of DIDs, users can customize DID content | Describe vehicle speed, temperature, oil quantity, etc. |
| Extended Information | It consists of a series of DIDs, and the content of DIDs is specified by BSW | Additional information describing the DTC, such as the number of burn-in cycles. |
2. Detailed explanation of DEM
2.1 Main functions of DEM
The full name of Dem is Diagnostic Event Manager, which is responsible for processing diagnostic fault events, storing diagnostic fault events and data associated with fault events (temperature, vehicle speed, etc. at the time of fault occurrence). In short, Dem plays the role of "central processing unit" for faults in the AUTOSAR architecture. User software modules only need to report faults to DEM, and all fault information processing is performed by DEM:
1. Before the fault is confirmed: Debounce anti-shake processing of the fault reported by the user module to ensure that the corresponding fault is not a false alarm fault.
2. When the fault is confirmed: the fault data when the fault event is confirmed is stored in NVM to ensure that the fault can be stored for a long time.
3. After the fault is confirmed: the aging and replacement of the fault, and the function that the fault can be cleared after the fault is repaired. For example, the check engine light on the instrument panel will go out after a period of time after the engine is repaired.
2.2 Relationship between DEM and other modules
1) DEM location in AUTOSAR architecture
Dem is located in the system service layer of AUTOSAR architecture, and the system service layer provides the following services:
1. Operating system scheduling and monitoring service, 2. Communication and network management service 3. Storage service 4. Diagnostic service (UDS communication service and fault service) 5. ECU status management service
As can be seen from the architecture diagram below, Dcm and Dem, as "Diagnostic Duo", provide all diagnostic services in a complete manner. The difference is that Dcm majors in "UDS diagnostic communication service", communicates directly with the communication protocol stack, and interacts with external diagnostic instruments to provide diagnostic communication services (10, 22 and other services); Dem majors in fault diagnosis services, and communicates with upper SWC, BSW Interact with modules, receive fault reports, and interact with NVM to use storage functions.
A UTOSAR architecture diagram
2) Dem and other module dependencies
Dem and other module relationship link diagram
NVM: Nvm can provide storage services for Dem to use, that is, to provide NVM BLOCK required for diagnosing faulty storage. It should be noted that Nvm provides two types of storage service interfaces for Dem, Nvm_WriteBlock() for DEM to store and diagnose faults in real time, and NvM_SetRamBlockStatus() for Dem to power off storage and diagnose faults. The above storage modes can be reflected in the DTC configuration properties.
DCM: As can be seen from the above figure, when DCM receives the 19 service (get Dtc) and 14 service (Clear Dtc) of the diagnostic instrument, it needs to obtain DTC data through Dem in real time and clear the DTC.
ECUM: Perform initialization and ShutDown operations on the Dem module.
SWC (Monitor): Monitor and diagnose the fault event Event, and report the Event status to Dem by using the Dem_SetEventStatus() function. Use Dem_SetOperationCycleState() to control the operation cycle state.
2.3 DEM Core Event
Before introducing the specific functions of DEM, first introduce the concept "Diagnostic event", which is also the most important element in the DEM module. For the AUTOSAR software architecture, DTC is only displayed to the user of the diagnostic instrument, while Event is the actual controller of DTC status, and Event is also the actual controller of diagnostic NVM data storage.
Readers will definitely have the following questions:
- Why introduce "Diagnostic event"?
- "Diagnostic event" source?
- What are the characteristics of "Diagnostic event"?
- How does "Diagnostic event" control DTC?
- How does "Diagnostic event" control diagnostic data storage?
Next, we will answer the above questions one by one.
1) The connection and difference between Event and DTC
the difference:
1. Description level: DTC is the description of faults at the system level, and Event is the smallest unit for fault monitoring at the software level.
Example: A certain motor fault may be caused by overvoltage, but the software cannot directly identify the fault. The software can only monitor whether the time event of overvoltage is generated, so as to calculate whether a DTC is generated.
2. Link relationship: multiple events can map the same DTC; but the same event cannot map multiple DTCs;
3. Visibility: DTC can be directly visible, but Event can only be seen through further means, sometimes only visible to ECU suppliers;
connect:
1. DTC represents the centralized performance of a certain type of event, and an event is a specific instance of a DTC; 2. The priority of an event determines the priority of a DTC; 3. The dependency between events determines the dependency of a DTC;
2) "Diagnostic event reporting method
As mentioned above, the SWC monitors the status of the fault Event, and can report the Event status to the DEM through Dem_SetEventStatus(EventId, EventStatus). So for SWC, how should the Event status be reported? Calling Dem_SetEventStatus periodically to report is periodic reporting; when the Event status changes, calling Dem_SetEventStatus to report is triggered reporting. The two reporting methods have their own advantages and disadvantages, as shown in the figure below, and there must be no one-size-fits-all approach.
Generally speaking, for small controllers, the number of events that need to be reported is not large, and you can choose to report periodically. For domain controllers, there are a large number of events that need to be reported. In order to ensure a stable load rate, trigger reporting should be selected.
3) What are the characteristics of "Diagnostic event"?
1.Event Kind
Event Kind can be divided into BSW Event and SWC Event according to the fault event reporting method.
| Event Kind |
source | Reporting method | Function name |
| BSW Event | BSW module | Standard C interface | Dem_ReportErrorStatus |
| SWC Event | SWC module | RTE interface | SetEventStatus（RTE） |
2.Event priority
For diagnosis, the number of fault events that can be stored and related data such as corresponding freeze frames is constant, which needs to be configured in advance by software development engineers. When the internal storage of fault events is full, the Event priority can solve the problem of how to store new fault events.
Generally speaking, the diagnosis priority setting is set by the diagnosis system engineer starting from the function of the whole vehicle and comprehensively evaluating the importance, safety and severity of the diagnosis fault. For example, the power failure of a car is far more serious than the air-conditioning failure, so the priority of power-related failures is generally higher than that of air-conditioning-related failures.
Diagnostic event priority has the following important characteristics:
1) The smaller the priority value of the diagnostic event, the higher the priority, and the value of 1 has the highest priority. 2) Event priority only plays a role when the diagnostic events are full, and the rest of the cases are stored according to the FIFO principle.
3.Event occurrence
As the name implies, Event Occurrence is a fault event reporting counter. The more fault reports, the greater the Event Occurrence value, indicating that the fault is older. The "new" and "old" fault tags will also play an important role in the arbitration mechanism of how to store new fault events, which will be explained in detail later.
Event occurrence has the following characteristics, as follows:
1. Each event memory entry has a corresponding Event occurrence.
2. The maximum value of Event occurrence is 255.
3. There are two configuration options for the counting method of Event occurrence:
| configuration properties | counting method |
| DEM_PROCESS_OCCCTR_TF | Bit0 (TestFail) jumps from 0 to 1, Event occurrence +1 |
| DEM_PROCESS_OCCCTR_CDTC | Bit0 (TestFail) jumps from 0 to 1 and Bit3 jumps from 0 to 1, Event occurrence +1 |
2.4 Event Memory storage content
Event, freeze frame, extended data, etc. have been described in detail above, so how are these data stored in DEM? DEM provides the concept of Event Memory, which combines Event, freeze frame, and extended data for unified management. Without further ado, let's start exploring Event Memory.
Event Memory classification:
| type | meaning |
| DemPrimaryMemory | Store EventId, Fault Status, Freeze Frame, Extended Data |
| DemMirrorMemory | |
| Permanent Event Memory | Used to store OBD-related DTCs |
The structure of Event Memory is shown in the figure below:
Event Memory Composition Architecture Diagram
S1: The Dem module must support Primary Memory, Mirror and Permanent memory can be selected according to user needs, generally not used.
S2: Primary Memory is a non-volatile storage space whose size is DemMaxNumberEventEntryPrimary for storing fault data. That is, Primary Memory consists of DemMaxNumberEventEntryPrimary Event Memory Entry.
Essentially, how much DemMaxNumberEventEntryPrimary is set, how many NVM Blocks NVM will provide for storing Primary Memory, and how much Event information can only be stored.
S3: The content stored in each Event Memory Entry includes: EventId, Occurance Counter, freeze frame, extended data, aging period, etc.
2.5 Event Memory management
When the SWC or BSW reports the Event, what processing will it eventually become the Event Memory in Flash?
As can be seen from the figure below, after the Event is reported, the following processing is required:
Event enable condition detection
Event controls DTC Bit update
Event Memory Retention
Event Memory management flow chart
1) Event enabling condition detection
Event enabling conditions are equivalent to a gate in Dem, and only when the conditions are suitable, Event can actually enter the processing flow of Dem.
Event enabling condition flow chart
It can be seen from the figure that it needs to go through many processes from the event reporting to the eventual control of the DTC bit transition in the second stage. Next, the above process will be explained in detail.
S1: First of all, it is necessary to judge whether the operation cycle is currently enabled. The operation cycle generally refers to the ignition cycle. An operation cycle can be regarded as a cycle of DTC detection. If the operation loop is enabled, start the following Enable Condition judgment, otherwise, exit the entire Event Memory management process directly.
S2: The Enable Condition judgment refers to an additional condition judgment added to the Event report. The Dem uses the corresponding interface for the SWC, and the SWC implements the attachment condition processing. Generally, it can be used to deal with some restrictions such as voltage and vehicle mode. If the Enable Condition condition is satisfied, then perform 85 service judgment; if the Enable Condition condition is not satisfied, then directly exit the Event Memory management process.
S3: If the 85 service is used to suppress the DTC enablement, then directly exit the entire Event Memory management process. If the 85 service is not executed, start the Event Debounce process.
S4: After Debounce, if the final Event result is Pass or Fail, then start the next stage of Event control DTC transition; otherwise, directly jump out and exit the entire Event Memory management process.
Event Debounce
"Debounce", as the name suggests, refers to the anti-shake processing of Events to prevent false positives of Events from causing false positives of DTC.
SWC reports Passed/Failed/PrePassed/Prefailed four states through Dem_SetEventStatus(EventId, EventStatus).
1) When SWC reports Passed and Failed states, Dem does not need to perform Debounce processing. 2) When SWC reports Prefailed and Prepassed states, Dem needs to perform Debounce processing.
In essence, the Debounce provided by Dem is to handle the state change from PrePassed/Prefailed to Passed/Failed through a specific mechanism.
Dem provides two debounce mechanisms, namely "Base Time" and "Base Counter".
1. Counter-based Debounce strategy
Several important parameters of the Counter-based Debounce strategy are as follows:
| parameter | meaning |
| FDC(Fault Detection Counter) |
Error counter, value range is -128-127 |
| DemDebounceCounterFailedThreshold | The Debounce Counter threshold that makes the Event diagnostic event status finally Failed |
| DemDebounceCounterPassedThreshold | The Debounce Counter threshold that makes the Event diagnostic event status finally Passed |
| DemDebounceCounterIncrementStepSize | When the SWC reports Prefailed, the error counter increments |
| DemDebounceCounterDecrementStepSize | When the SWC reports Prepassed, the error counter increments |
Debounce mechanism based on Couneter
As shown in the figure above, in the Counter-based Deboucne mechanism, Dem will provide a counter (FDC) to record the judgment result. When the Event status reported by SWC to Dem is Prefialed, the counter will increase according to the step size. When it reaches the set When the limit value is reached, the fault status becomes Failed. When the reported state is PrePassed, the counter decreases according to the step size, and when the set limit is reached, the fault state becomes Passed.
2. Time-based Debounce Strategy
Several important parameters of the time-based Debounce strategy are as follows:
| parameter | meaning |
| DebounceTimeBasedTaskTime | basic testing cycle |
| DemDebounceTimeFailedThreshold | Define how many DebounceTimeBasedTaskTime cycles it takes for the fault status to jump from PreFailed to Failed |
| DemDebounceTimePassedThreshold | Define how many DebounceTimeBasedTaskTime cycles it takes for the fault state to jump from PrePassed to Passed |
Time-based debounce mechanism
Under this strategy, when the SWC starts reporting the Event status, the Dem module will provide a timer to record the result of the judgment, and the growth direction of the timer is determined by the Event status. When the timer accumulates to a certain threshold, the fault status changes to Passed or Failed.
3) Event control DTC status update
When the Event goes through a series of processing, it can finally update the DTC status. The update logic of the 8 bits of the DTC is as follows:
DTC Bit0 update logic
| Bit update | condition |
| 0 -> 1 | After debounce, the final reporting status is Failed |
| 1 -> 0 | After debounce, the final reported status is PassedOR use 14 service to clear DTCOR reset event status |
DTC Bit0 update logic diagram
DTC Bit1 update logic
| Bit update | condition |
| 0 -> 1 | After debounce, the final reporting status is Failed |
| 1 -> 0 | Operation Loop Update OR Clear DTC with 14 Service |
DTC Bit1 update logic diagram
DTC Bit2 update logic
| Bit update | condition |
| 0 -> 1 | After debounce, the final reporting status is Failed |
| 1 -> 0 | (operation cycle update AND TestFailedThisOperationCycle == 0) OR use 14 service clear DTCORTestNotCompeleteThisOperationCycle == 0 |
DTC Bit2 update logic diagram
DTC Bit3 update status
| Bit update | condition |
| 0 -> 1 | After debounce, the final reported status is FailedAND Fialure Counter > = Fault Confirmation Threshold |
| 1 -> 0 | Aging condition reached OR DTC cleared with 14 service OR Fault overflow replaced |
DTC Bit3 update logic diagram
DTC Bit4 update logic
| Bit update | condition |
| 0 -> 1 | After debounce, the final reporting status is Failed |
| 1 -> 0 | Clear DTC with 14 services |
DTC Bit4 update logic diagram
DTC Bit5 update logic
| Bit update | condition |
| 0 -> 1 | After debounce, the final reporting status is Failed |
| 1 -> 0 | Clear DTC with 14 services |
DTC Bit5 update logic diagram
DTC Bit6 update logic
| Bit update |
condition |
| 0 -> 1 |
After debounce, the final reporting status is Failed |
| 1 -> 0 |
Clear DTC with 14 services OR Operation cycle update |
DTC Bit6 update logic diagram
DTC Bit7更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为FailedAND 点灯条件满足 |
| 1 -> 0 | 使用14服务清除DTCOR点灯条件不满足 |
DTC Bit7更新逻辑
4）Retention条件检测
当DTC状态完成更新后，Dem将开始进行Retention条件检测。Dem给用户提供多种策略用以判断是否需要分配Event Memory Entry。分配策略由配置DemEventMemoryEntryStorageTrigger决定，具体如下面表格所示：
| DemEventMemoryEntryStorageTrigger | 分配条件 |
| DEM_TRIGGER_ON_TEST_FAILED | DTC bit0 由0跳变成1 |
| DEM_TRIGGER_ON_CONFIRMED | DTC bit3 由0跳变成1 |
| DEM_TRIGGER_ON_PENDING | DTC bit2 由0跳变成1 |
| DEM_TRIGGER_ON_FDC_THRESHOLD | DTC bit0 由0跳变成1ORDTC bit1由0跳变成1ORDTC bit2由0跳变成1ORDTC bit3由0跳变成1 |
5）Event Memory Retention处理
Event上报经过了使能条件检测，Event控制DTC Bit位状态更新，Retention条件检测重重难关，最终被允许进入Event Memory，Dem会怎样将Event（DTCs），DTC状态，快照，扩展数据存入Event Memory中呢？
基本思路如下：
Event Memory Retention处理机制
S1: Search in all Event Mmeory Entry of Event Mmeory, check whether the Event and related data have been stored in Event Memory, if already exist, enter Event Memory Entry Storage. If it does not exist, find space in the Event Memory to store the content of the Event. If the space in the Event Memory is full, you need to use the Replacement mechanism.
S2: When entering the Event memory Storage, the Occurance Counter needs to be incremented by 1 to determine whether to update the freeze frame and expand the data.
Event Displacement processing
The Event Memory stores the Event Memory Entry whose number is DemMaxNumberEventEntryPrimary. When the Event Memory Entry is full, Replacement is required, that is, how to store the newly added Event is determined according to a certain strategy. The Dem module provides a complete mechanism for Replacement, which has three core principles:
1.Event Priority (the smaller the number, the higher the storage priority) 2.Event Active or Event Passive status (Active priority is higher than Passive priority) 3.Event Occurance Counter (the storage priority of the most recent occurrence is higher than that of the previous one) The replaced Event corresponds to Bit2, Bit3 and Bit5 in DTC will be set to 0.
The figure below shows the whole set of Event Displacement mechanism, reflecting the role of the three core principles in the replacement mechanism.
Event Displacement Mechanism
Summarize
DEM is an AUTOSAR basic software module with DTC as the core, which realizes the functions of monitoring, reporting and storage of DTC. If you need to further study AUTOSAR diagnosis, you also need to study DCM, Doip, Cantp and other modules systematically.
Source | Automotive Electronics Embedded