AUTOSAR基础篇之Event

继上文《AUTOSAR基础篇之DTC》中提到event是故障监控的基本单元，本文将从Event的使能条件（Enable Condition）、上报方式、去抖动策略（DebouncingStrategy）、优先级（Priority）、Displacement、依赖关系图（Dependency Node）以及event Storage Condition等七个常见属性进行展开跟大家聊聊：

 1 Event 使能条件

作为事件监控的基本单元，Event能否开启监控绝大部分情况下都需要满足一定条件，只有这样，才能够保证Event监控是否存在意义。

若不加以相关的限制条件，那么会导致增加诸多的信息干扰导致最终无法快速排查Root Cause，说的简单点，就是起到了Event过滤器的作用。通过该Event过滤器，可以得到你所允许上报或者抑制的Event上报。

·      比如典型实例就是当总线Busoff发生时，同时会发生很多报文丢失的故障，但是这些timeout故障只是sequential events，是顺理成章的事。但我们不希望报出这些sequential events，就会为这些Event添加相应的Busoff的使能条件。即只有当总线没有发生Busoff时，才允许记录这些Timeout的events, 才显得更有意义！

·      比如上电经过特定时间之后才允许开启电压监控，因为ECU刚上电电压不稳定是一个正常过程，应当予以过滤掉，故而为电压监控的event添加上电初始化时间的使能条件。即在上电特定时间内禁止电压相关事件监控，其余事件可以正常开启监控；

·      再比如有些event需要获取KL15状态信息或者其他的一些综合条件，才能够进行event上报，因此使能条件可以自由根据客户的需求进行添加，当然如果涉及到event之间的依赖关系，也可以利用Dependency Node来起到Event过滤器的作用，后面会继续讲到。

event的使能条件就相当于event过滤器，可以实现event在某种特定条件下event才被允许上报，为了更为清楚的了解到event上报的全部流程，如下图1所示：

 图1 event上报处理流程图

 在上图中可以看出，一个Event从上报到最终被存储需要经历种种千辛万苦的考验，才能最终落地生根，修成正果被你所看到。

S1：首先，需判断是否开启了Operation Cycle，如果是，则继续下面Enable Condition的判断，否则就直接结束；

S2：若Enable Condition Fulfilled，则进行85诊断服务的判断，若不满足，则直接结束；

S3：若此时使能了85服务，则直接结束，若没有，则可以继续往下进行Debouncing；

S4：经过Debouncing之后，若Event发生变化，则也会反映到DTC Status的变化，若没有变化或者没有结果，便可以直接结束；

S5：到此并没有结束，Event能否正确存储至NVM中，取决于是否满足Storage Condition, 同时，在满足存储条件之后，若event entry已满，能否最终存储还取决于event优先级以及event之间的依赖关系等。 

2

 Event 上报方式

      当Event满足上述的使能条件之后，其触发的方式主要分为两种：循环上报型与Event触发型，两者的区别显而易见，前者Event一旦触发，就会循环不断地上报event状态，后者则是Event状态发生变化的时候，才会触发一次，并不会一直上报。

有小伙伴就问了，为啥要做这两种区别呢，故障一旦触发，一直上报不就行了吗？问的在理。

这是因为从软件架构设计的层面考虑到，event上报来源于各个SW-C模块，经过RTE传输至故障处理模块，但是模块上报的Event数目非常多，如果都采用Polling上报的方式，那么无疑会增加RTE传输数据的负担，而且对于故障处理模块而言，其实只需知道你的最新状态即可。

所以在这种情况下，采用Event触发型无疑是更明智的选择，即仅当Event状态发生变化时才会触发一次上报。如下图2所示，体现了两种不同上报方式的优缺点以及应用场合。

图2 Event触发方式的对比

 从上图2可以看出，无论是采用循环上报还是Event触发方式上报，本质上都是调用相同的DEM API函数接口来实现Event进一步的处理。

因此，在event上报选择方式上面，应当结合图中优缺点综合考虑，切不可一刀切，应当建立在软件架构的基础上去实现客户的需求，才能保证选择方式的合理性。

3

Event去抖动策略

当Event上报之后交由故障处理模块处理，在处理的过程中有一个非常重要的环节：去抖动策略，该策略就是为了防止所有故障误报应运而生 ，只有经历了去抖动算法之后，Event的最终状态才能够被确定，也就是PASS、FAIL, No Result这三类。

一般而言，去抖动策略也分为两种：TimeBase与Counterbase。

TimeBase是通过计时来完成对Event的去抖动的过程，而CounterBase则是通过计数来完成对Event的去抖动，比如timeout类故障，可以直接采用TimeBase的策略来完成去抖动，比如Event触发型可以采用Counterbase来完成去抖动。

下面结合AUTOSAR DiagnosticEvent Manager标准文档来针对这两类去抖动算法进行讲解：

3.1 TimeBase Debouncing

如下图3所示，将图划分为3个区域，区域1为Event上报状态区域，区域2为Event TimeBase的去抖动过程，区域3为Event去抖动之后的评估结果。

·      在区域1中，纵坐标表示Event上报的状态类型，有FAILED、PREFAILED、PREPASSED、PASSED四种基本状态，该状态通过DEM提供的函数接口来体现，具体细节可以参考之前的文章AUTOSAR-DEM模块几点思考！，在这里不做过多赘述。在该区域中，每上报一次不同的event状态，区域2中的FDC（Fault Detection Counter）都会发生相应的变化；

·      在区域2中，当区域1上报一次PREFAILED时，FDC会基于tFailed的时间阈值换算为线性关系上升至阈值（127），若没有event 状态更新的上报，将保持至阈值不变；当区域1上报一次与上次Event状态不同的状态如PREPASSED时, FDC无论如何首先会回归至0，然后基于tPassed的时间换算成对应的线性关系下降至阈值（-128）；如果在下降或者上升的过程中发生状态的变化，如下图从PREPASSED变为PREFAILED,那么在下降的某个时刻会首先回归至0，然后再继续以一定斜率上升至阈值（127）；如果上报的Event状态直接就是PASS或者FAIL，那么FDC会直接到达至相应阈值-128（Passed）或者127（Failed）。

·      在区域3中，纵坐标是event经过去抖动算法之后的最终评估结果，亦称为故障成熟结果，分为PASS,FAIL两种结果。

• 当FDC == 127（Failed）时，EventStatus == FAIL;

• 当FDC == -128（Passed）时，Event Status == PASS;

• 

图3 TimeBase 去抖动算法

 通过上述场景的分析可以得出：对于TimeBased的去抖动算法，主要适用于在满足连续时间内故障便可以成熟的event，如timeout类事件或者其他跟时间密切相关的Event。

当然，一般而言，如果能够用timebased的时间也可以转化为Counterbase的算法来实现，因为两者本质就是基于时间来实现去抖动算法。 

3.2 CounterBase Debouncing

如下图4所示，相比上图3，除了区域2有所区别以外，区域1与3含义与上图一致。在讲解下图之前，需要解释几个专有名词如下所示：

·   Internal DebouncingCounter(IDC): 表示用户自定义的debouncing counter，该IDC与FDC会在软件内部转化为一种线性比例关系；

· DemDebounceCounterFailedThreshold: 表示事件Fail时的IDC阈值（eventactive）；

· DemDebounceCounterPassedThreshold: 表示事件Pass时的IDC阈值（eventpassive）；

·   DemDebounceCounterIncrementStepSize: 表示事件每上报一次Prefail时IDC上升的步距；

·  DemDebounceCounterDecrementStepSize: 表示事件每上报一次PrePass时IDC下降的步距；

· DemDebounceCounterJumpDownValue: 表示如果Jump-Down行为使能，在当前的IDC大于此值时，IDC就会首先跳转到该值处，然后才进行接下来的Debouncing行为；

· DemDebounceCounterJumpUpValue：表示如果Jump-Up行为使能，当前的IDC小于此值时，FDC就会首先跳转到该值处，然后才进行接下来的Debouncing行为；

1.    如图中所示,每当Event以PreFailed上报一次，IDC就会上升一次步距，该步距长度为DemDebounceCounterIncrementStepSize，直至到达DemDebounceCounterFailedThreshold，Event判定结果为FAIL; 

2.    同理，每当Event以PrePassed上报一次，IDC就会下降一个步距，该步距长度为DemDebounceCounterDecrementStepSize，直至到达DemDebounceCounterPassedThreshold，Event判定结果为PASS

3.    若Event直接以Failed或者Passed上报，那么IDC就会直接到相应的Pass或者Fail阈值；

4.    如没有新的Event 状态上报，那么就会IDC就会保持当前的IDC值不变；

5.    如果使能了Jump-Down或者Jump-Up行为，那么就会根据上述DemDebounceCounterJumpDownValue或者Dem Debounce Counte - rJumpUpValue的解释跳转到相应的位置，然后进行Debouncing行为；

图4 CounterBased 去抖动算法 

该CounterBased的算法主要适用于Event上报型的故障，基于次数来决定Event是否成熟，因此，无论使用上述哪种Debouncing算法，只要合理并正确使用，将能够大大减少故障的误触发，提高整个系统的稳定性与鲁棒性!

4

Event Priority

Event优先级的提出是为了解决当ECU内部存储的Event入口已满的前提下，如何决定当前发生的Event怎样存储的问题，到底是舍弃当前新产生的Event还是剔除已存入却已经恢复或者非Active状态的Event来保证最新Active状态的Event存入NVM，这对于故障分析处理也是十分必要的。一般如下所示，Event优先级存在以下几个特点，如下图5所示： 

图5 Event优先级的基本特征 

有一点需要说明的是针对多个event Map至同一DTC的场合，对于客户可见的同一DTC下所map的所有event一般都应赋予同一优先级，而对于内部event的处理，可以采用不同的优先级，即不需要考虑是否Map同一DTC。

这样做的好处在于对客户而言，可以给到统一的故障信息，对供应商而言，可以保留最为重要的event信息，一举两得！同时，Event的优先级也会在下面Event Displacment的过程中发挥至关重要的作用。

5

Event Displacement

 一般而言，对于ECU内部存储event的数量是一定的，通常也称为event memory entry，当前该大小取决于ECU本身存储空间，但一般不少于10个event memory entry。

而event displacement仅发生在当event memory entry已满的情形下，应按照一定的策略来决定如何对新增的event进行存储。根据AUTOSAR标准，其提供了一套较为行之有效的策略供参考，且这一套机制在DEM模块实现，该模块按照这下列三大原则来实现Event displacement：

·      Event Priority（这是最重要的评判原则，数字越小存储优先级越高）；

·      Event Active或者Passive状态（Active存储优先级高于Passive优先级）；

·      Event Occurence time（最近发生的存储优先级高于较早发生）；

为了更好的表达这三者在Event displacement中如何发生作用，以下图2中所示，该图以非排放相关系统故障监控为例，清晰表达了这三者之间如何协同作用来完成event的存储。

图6 Event Displacement Strategy

6

Event Dependency Node

在谈Event Dependency之前，我们需要引入一个概念：MonitoringComponent， 该组件代表整个ECU系统可被划分为几个大的组件来统一监控，不至于对所有Event离散型监控，因为Event也是存在类别或者依赖关系，Event之间的这些关系同样的可以映射到MonitoringComponent中。

比如当某个Event发生时，有些Event就会必定发生，那么这些Event是不是应当过滤掉呢；当某组件模块发生模块，那么其依赖模块是不是也会存在问题呢？

因此该组件模式就会在此发挥十分重要的作用，如下图3所示，就表现了ECU硬件组件以及COM组件模块之间的依赖关系。

图7 Event Dependencies

 通过上图我们能简要知道对于存在依赖关系的event可通过上述Dependency Gragh 来体现。那么，具体到软件内部，一般做法又是如何处理的呢？

接下来我们来看下图4所示的示例来完整解释对于上述过程的一般性做法:

图8 Event Dependency Gragh

正如前面讲到，当某个Event发生时，其他Event也会相继发生，那么此时我们称前者为Causal Fault， 而后者则被称为Consecutive Fault。

对于Causal Fault ECU会正常执行Event handling，但是对于Consecutive Fault则会直接Ignore掉。下面我们假定五种情形，来看看DemComponent如何发挥作用：

A.   若Event A, Event B同时发生或者A先于B发生时，Event A则被视为CausalFault，而Event B作为ConsecutiveFault直接忽略掉；

B.    若Event B已经发生时，Event E就会当做Consecutive Fault直接忽视掉，因为Component 1即为Failed状态，其子Component下的Event都会被视为Consecutive Fault忽视；

C.   若Event E发生时，Event H发生时，两者都会被视为Causal Fault完成正常的Event handling，因为两者并没有存在父子关系，DEM模块会平等对待此类型的Component；

D.   若Compopnent 2模块忽视自身优先级且Component 1 处于Not Fail状态时，那么该模块2下所有的event都是平等关系，按照正常Causal Fault处理；若此时Component 1为Fail状态时，那么Component2下的所有Event均会被视为Consecutive Fault来处理；

E.    若Component 3被设置成Not Available，那么该模块也会被视为不存在整个ECU系统中，而其下的所有Event均会被设置为不可见状态；

7

Event Storage Condition

当一个Event经过上述的Event handling过程之后，其最终能否为其分配Event Memory Entry不仅取决于Event memory是否已满，在此之前还有一关要过，那就是Storage Condition。

一个Event 可以存在0个或者多个StorageCondition，Storage Condition条件的设定可由DEM提供API函数Dem_SetStorageCondition来实现。

每个Storage Condition可根据客户需求自由实现。如下图5所示，就体现了不同Event是否满足Storage Condition下的DEM处理过程。

 

图5 Event Storage Condition Processing

如上图所示，EventA的StorageCondition为1，EventB的StorageCondition为1,2，Event C的Storage Condition为1,2,3。

上述Event A、B、C在经过Storage Condition Filter之前都会进行前置处理即EnableCondition Filter与Event handling过程。

假定这三个event都满足各自的Enable Condition，但当前仅有Storage Condition1成立，那么仅存在Event A被存入Event Memory，Event B与C则会在这一环节被过滤，无法存储至event Memory中。

不过Event B、C虽不满足上述的相应的StorageCondition, 但需要特别注意的是event B、C的Status的Bit 3（Confirmation bit）位会不为1，其余Bit还是执行正常的event handling，以便来表征该类Event 未被最终存储至Event Memory中。

除了上述列出来的常见的七大属性以外，Event还有很多属性，如Event Retention、Event Status，Aging等，大家如果感兴趣，可以多多参考AUTOSAR的相关文档来进行学习。