I would like to dedicate this limerick to the many friends who are celebrating the New Year in different places like me. I wish you all good health, all your wishes come true, and great energy in the new year! Although celebrating the New Year in a different place is a bit less lively than in my hometown, it also has a bit more purity and freedom of independent thinking.
Well, taking advantage of this situation, I started writing hard again, and I can't wait to share my knowledge and understanding of the event (commonly known as Fault) in the AUTOSAR basic module DEM with my friends.
Following the mention in the DTC of the AUTOSAR Basics chapter above that event is the basic unit of fault monitoring, this article will cover the event's enable condition (Enable Condition), reporting method, debouncing strategy (Debouncing Strategy), priority (Priority), and displacement , dependency graph (Dependency Node) and event Storage Condition and other seven common attributes to expand and chat with you:
1.Event enabling conditions
As the basic unit of event monitoring, in most cases, whether Event can enable monitoring must meet certain conditions. Only in this way can we ensure whether Event monitoring is meaningful.
If relevant restrictions are not imposed, a lot of information interference will be added, making it impossible to quickly troubleshoot Root Cause. To put it simply, it functions as an Event filter. Through this Event filter, you can get the Event reporting that you allow to report or suppress.
For example, a typical example is that when the bus busoff occurs, many message loss failures will occur at the same time, but these timeout failures are only sequential events and are a matter of course.
But we don't want to report these sequential events, so we will add corresponding Busoff enabling conditions for these Events. That is, it is more meaningful to allow recording of these Timeout events only when the Busoff does not occur on the bus!
For example, voltage monitoring is only allowed to be turned on after a specific period of time after power-on. Because voltage instability just after the ECU is powered on is a normal process and should be filtered out. Therefore, the enable condition of the power-on initialization time is added to the voltage monitoring event.
That is, the monitoring of voltage-related events is prohibited within a specific time after power-on, and the monitoring of other events can be enabled normally;
For another example, some events need to obtain KL15 status information or other comprehensive conditions before they can report the event. Therefore, the enabling conditions can be freely added according to customer needs. Of course, if dependencies between events are involved, Dependency can also be used. Node plays the role of Event filter, which will be discussed later.
The enabling condition of an event is equivalent to an event filter, which allows events to be reported only under certain specific conditions. In order to understand the entire process of event reporting more clearly, as shown in Figure 1 below:
As you can see from the picture above, an Event needs to go through all kinds of arduous tests from being reported to being finally stored, before it can finally take root and be seen by you.
S1 : First of all, it is necessary to judge whether the Operation Cycle is enabled, if yes, proceed to the judgment of Enable Condition below, otherwise it will end directly;
S2 : If Enable Condition Fulfilled, then perform 85 diagnosis service judgment, if not satisfied, then end directly;
S3 : If the 85 service is enabled at this time, it will end directly, if not, you can continue to debouncing;
S4 : After debouncing, if the Event changes, it will also reflect the change of DTC Status, if there is no change or no result, it can be ended directly;
S5 : It is not over here. Whether the event can be stored correctly in NVM depends on whether the Storage Condition is met. At the same time, after the storage condition is met, if the event entry is full, whether the event can be finally stored depends on the event priority and the event dependencies among others.
2.Event reporting method
When an Event meets the above enabling conditions, its triggering methods are mainly divided into two types: cyclic reporting type and Event triggering type. The difference between the two is obvious. Once an Event is triggered in the former, the event status will be continuously reported in a loop, while in the latter It will only be triggered once when the Event status changes, and will not be reported all the time.
Some friends asked, why do we make these two distinctions? Once a fault is triggered, can't we just keep reporting it? It makes sense to ask. This is because from the perspective of software architecture design, event reporting comes from each SW-C module and is transmitted to the fault processing module through RTE, but the number of events reported by the module is very large.
If the Polling reporting method is adopted, it will undoubtedly increase the burden of RTE to transmit data, and for the fault handling module, in fact, it only needs to know your latest status, so in this case, using the Event trigger type is undoubtedly the best A more sensible choice is to trigger a report only when the state of the Event changes.
As shown in Figure 2 below, it reflects the advantages, disadvantages and application scenarios of two different reporting methods.
As can be seen from Figure 2 above, whether it is reported in a circular reporting or event-triggered manner, the same DEM API function interface is essentially called to implement further processing of the event. Therefore, the event reporting selection method should be combined with the figure. The advantages and disadvantages should be considered comprehensively, and one size does not fit all. It should be based on the software architecture to achieve customer needs to ensure the rationality of the selection method.
3.Event debounce strategy
When the event is reported, it is handed over to the fault processing module for processing. There is a very important link in the processing process: the debounce strategy. This strategy is to prevent all fault false alarms. Only after going through the debounce algorithm, the Event The final state can be determined, that is, the three categories of PASS, FAIL, and No Result.
Generally speaking, debounce strategies are also divided into two types: TimeBase and Counterbase. TimeBase completes the debouncing process of Events through timing, while CounterBase completes the debouncing process of Events through counting, such as timeout faults. You can directly use TimeBase's strategy to complete debouncing.
For example, the event-triggered type can use Counterbase to complete debounce. The following is an explanation of these two types of debounce algorithms in conjunction with the AUTOSAR Diagnostic Event Manager standard document:
3.1 TimeBase Debouncing
As shown in Figure 3 below, the diagram is divided into three areas. Area 1 is the Event reporting status area, Area 2 is the debounce process of Event TimeBase, and Area 3 is the evaluation result after Event debounce.
In area 1, the ordinate represents the status type reported by the event. There are four basic statuses : FAILED, PREFAILED, PREPASSED, and PASSED . This status is reflected through the function interface provided by DEM. For specific details, please refer to the previous article AUTOSAR-DEM Module Something to think about ! I won't go into too much detail here.
In this area, every time a different event status is reported, the FDC (Fault Detection Counter) in area 2 will change accordingly; in area 2, when area 1 reports a PREFAILED, the FDC will be converted based on the time threshold of tFailed. It is a linear relationship that rises to the threshold (127). If no event status update is reported, it will remain unchanged until the threshold;
When area 1 reports a state that is different from the last Event state, such as PREPASSED, FDC will first return to 0 anyway, and then convert the corresponding linear relationship based on the time of tPassed to fall to the threshold (-128); if it is falling or
rising The state changes during the process, as shown in the figure below from PREPASSED to PREFAILED, then it will first return to 0 at a certain moment of the decline, and then continue to rise to the threshold (127) with a certain slope;
If the reported Event status is directly PASS or FAIL, then the FDC will directly reach the corresponding threshold -128 (Passed) or 127 (Failed).
In area 3, the ordinate is the final evaluation result of the event after the debounce algorithm, also known as the fault maturity result, which is divided into two results: PASS and FAIL.
When FDC == 127 (Failed), Event Status == FAIL;
when FDC == -128 (Passed), Event Status == PASS;
Through the analysis of the above scenarios, it can be concluded that the TimeBased debounce algorithm is mainly suitable for events that can mature after failures within a continuous time, such as timeout events or other events that are closely related to time.
Of course, in general, if timebased time can be used, it can also be converted into Counterbase algorithm, because the essence of the two is to implement the de-jitter algorithm based on time.
3.2 CounterBase Debouncing
As shown in Figure 4 below, compared to Figure 3 above, except that area 2 is different, the meanings of areas 1 and 3 are consistent with the above figure. Before explaining the figure below, a few proper nouns need to be explained as follows:
Internal Debouncing Counter (IDC): Indicates a user-defined debouncing counter, and the IDC and FDC will be converted into a linear proportional relationship within the software; DemDebounceCounterFailedThreshold:
Indicates the IDC threshold when the event fails (event active);
DemDebounceCounterPassedThreshold : Represents the IDC threshold when event Pass (event passive);
DemDebounceCounterIncrementStepSize : Indicates the step size of IDC increase every time the event is reported as Prefail;
DemDebounceCounterDecrementStepSize : Indicates the step size of IDC decrease every time the event is reported to PrePass;
DemDebounceCounterJumpDownValue : Indicates that if the Jump-Down behavior is enabled, when the current IDC is greater than this value, the IDC will first jump to this value, and then proceed to the next Debouncing behavior;
DemDebounceCounterJumpUpValue : Indicates that if the Jump-Up behavior is enabled and the current IDC is less than this value, the FDC will jump to this value first, and then proceed to the next Debouncing behavior;
As shown in the figure, whenever an Event is reported as PreFailed, the IDC will increase the step distance by one step. The step length is DemDebounceCounterIncrementStepSize until it reaches DemDebounceCounterFailedThreshold, and the Event judgment result is FAIL;
Similarly, whenever an Event is reported as PrePassed, the IDC will drop a step, the length of which is DemDebounceCounterDecrementStepSize, until it reaches DemDebounceCounterPassedThreshold, and the Event judgment result is PASS;
If the Event is directly reported as Failed or Passed, then the IDC will directly reach the corresponding Pass or Fail threshold;
if there is no new Event status reported, then the IDC will keep the current IDC value unchanged;
If the Jump-Down or Jump-Up behavior is enabled, it will jump to the corresponding position according to the above explanation of DemDebounceCounterJumpDownValue or DemDebounceCounterJumpUpValue, and then perform the Debouncing behavior;
The CounterBased algorithm is mainly suitable for Event reporting type faults. It determines whether the Event is mature based on the number of times. Therefore, no matter which of the above debouncing algorithms is used, as long as it is used reasonably and correctly, it will greatly reduce the false triggering of faults and improve the efficiency of the entire system. Stability and robustness!
Finally, since there are many attributes related to Event, which are difficult to digest quickly at one time, we will further discuss and learn about the four attributes of Event Priority, Displacement, Event Dependency node and Event Storage Condition in Event (Part 2). If you know what happened next, please listen to the next chapter. I also hope that my friends can give me more advice, and I will bring more exciting articles in the future.
If you think it is helpful to you, please like, follow and forward. For more exciting content, please pay attention to my technology sharing public account:
Technology sharing public account: My opinion on ADAS and ECU
Reply to the keyword "Add Group" in the background of the public account, and you can join the AUTOSAR technical exchange group for free to discuss hot topics such as CP, AP, SOA, information and functional security!
